Possible timing problems after a bios upgrade.
After upgrading to a new bios (dated 06/14/2001) on EPOX EP-8KTA3+ motherboard I have the following problems: - The SB128 PCI (module es1371) plays about twise slower than normal. - The via UDMA shows about 15Mb/sec instead of ~35Mb/sec. The text from the bios upgrade says: * Fixed compatibility with nVidia Geforce 2 MX AGP card causing system hangs while running 3DMark2001. * Changed method to show AMD K7 CPU FSB. * DRAM Bank-Interleave will be disabled if VCM SPD ROM is bad (or fails). The windows behaviour did not alter (at least I did not notice). An ideas? Best, Yarick. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: proc_file_read() question
On Mon, 25 Jun 2001, Martin Wilck wrote: > Hi, > > the "hack" below in proc_file_read() fs/proc/generic.c (2.4.5) > irritates me: > > If I do use "start" for a pointer into a memory area > allocated in read_proc, will it be always guaranteed > that (start > page)? > > If no, this will IMO lead to spuriously wrong output. > If yes, I'd like to understand why. Shhh ;-) Last time that hack was mentioned, someone wanted to _remove_ it. It's a very nice little hack to have around, and IKD uses it. -Mike diff -urN linux-2.4.4.virgin/fs/proc/generic.c linux-2.4.4.ikd.mike/fs/proc/generic.c --- linux-2.4.4.virgin/fs/proc/generic.cMon Dec 11 22:45:42 2000 +++ linux-2.4.4.ikd/fs/proc/generic.c Sun Dec 17 07:58:56 2000 @@ -104,6 +104,11 @@ * return the bytes, and set `start' to the desired offset * as an unsigned int. - [EMAIL PROTECTED] */ + /* Ensure that the data will fit when using the ppos hack, +* otherwise userland receives truncated data. +*/ + if (n > count-1 && start && start < page) + break; n -= copy_to_user(buf, start < page ? page : start, n); if (n == 0) { if (retval == 0) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
bad file descriptor
Hello all, i am facing a problem on my Red Hat Linux 6.2 machine. When i boot in my Linux box it boot properly till it reaches the stage where it says "Press I for interactive setup" >From there it starts giving me errors like this : - Mounting proc file system dup2 : Bad File Descriptor [FAILED] Configuring kernel parameters dup2 : Bad File Descriptor [FAILED] Loading default keymap/etc/rc.d/rc.sysinit : /dev/null : read only file system Activating swap partition dup2 : Bad File Descriptor [FAILED] Seting hostname localhost.localdomain : Bad File Descriptor [FAILED] Checking root filesystem : Bad File Descriptor [FAILED] An error occured during file system check For maintance mode give password [ctrl-d for normal setup] when I give root password i can log in as single user and it gives this message the moment I log in: bash: /dev/null :Read only file system kcd : cannot create file /root/.kcd.newdir Broken pipe. When i press ctrl-D for normal login the machine reboots. I tried running fsck, e2fsck, checked for bad blocks and made force checking too. still the problem is not solved. This system was running perfectly for 6-7 months. Please help. thanks in advance and waiting for the reply. -- Best regards, shantanu mailto:[EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
interrupt problem....
I am experiencing a strange problem. I am doing a continuous DMA for long hours using a card on my system. In my code I enable interrupts and clear the interrupts in the interrupt handler which is called on completion of every DMA cycle. Now, the program works fine for say 16-20 hours but I think when the debug files'(where i put some debug information for each DMA cycle + system log files etc) size becomes too large, card stops generating interrupts. 1. There is a bit in card that tells that DMA is complete 2. There is a bit in card that tells card to generate interrupt when DMA is complete 3. If we clear the above two bits, the interrupt handling is complete Now, DMA is getting complete as the bits specified in the point 1 and 2 are getting set. I have added a 'printk' in the interrupt handler to see whether the card is generating interrupts or not. Card stops generating interrupt. Even if I delete all the debug files and start my program again, same thing happens. After I reboot the system and run my program, the card starts working properly with same code. I have noted following things: a) If I delete all the system log files and restrict the size of my debug file, the code runs fine for more than 48 hours. Basically I stop the program after having a 48 hour run. b) If the system log files has large size and I do not delete them before starting my program, the card stops generating interrupts after 16-20 hours of run. Any pointers to the problem.. Regards, Daljeet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] rio500 devfs support
On Mon, Jun 25, 2001 at 05:12:01PM -0500, Gregory T. Norris wrote: > I was thinking of doing some similar updates this evening after work. > Darn it... now I have to find something else to do! :-) > > Going by this morning's comments from Richard Gooch, it sounds like the > > if (rio->devfs == NULL) > dbg("probe_rio: device node registration failed"); Just don't have it be using a call to "err()" like the printer.c file does. Loads of users wondering why they have an error message in their logs, yet their printers still work. That's why I made it dbg(). But yes, I agree that it doesn't have to be there at all. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Reg Kernel Debugger kgdb
Hi, I couls see http://kgdb.sourceforge.net/ the kgdb for 2.4.5 kernel version. Can I use the same for 2.2.14 kernel which I am using? If so how can I use gdb.bz2 downloaded file. I have this downloaded to my windows machine and have ftp ed to my linux machine to my home directory. Please tell me how I should go about it. Thanks in advance, Regards, sathish.j - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
> /> > GEM was a gui from Digital Research I believe. / > /> > Geoworks/Geos was a seperate entity. / > /> / > /> Ah, the DR-DOS answer to dosshell/windows. Cool. (I used Dr. Dos > byt never / > /> tried its gui.) / > > Actually I believe GEM predates DR-DOS, and except for being > made by the same company I don't think they were ever related. > > Eric Well I think I remember that DR-DOS was the name that Caldera gave to the Digital Research OS, previously known as GEMDOS, when then bought the company. GEMDOS was the official OS under the GEM Gui, but GEM was also able to run with MS-DOS and TOS (the Atari OS). Geoworks / Geos isn't a Digital Research product, but has been developped by guys who ran away from Digital when it has been bought by Novell... Some guys told me that they worked with Geos and that it was really closed with the internal "GEM spirit" Regards. Jocelyn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ext3-2.4-0.0.8
ext3 patches against kernels 2.4.5, 2.4.6-pre5 and 2.4.5-ac17 are available at http://www.uow.edu.au/~andrewm/linux/ext3/ Almost all testing thus far has been against 2.4.5. Known problems in 0.0.8 are: - A theoretical deadlock with quotas in -ac. This is proving impossible to demonstrate, and will be fixed in 0.0.9. - A fairly straightforward deadlock with quotas in 2.4.5[-pre]. This will probably be fixed in 0.0.9 as a side-effect of the version 2 quota fix. We wouldn't encourage people to put all their data on ext3, destroy their backups and then play russian roulette with power cords; however this software is in pretty good shape. Please test, and send any problem reports to [EMAIL PROTECTED] Thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] wrong disk index in /proc/stat
On Mon, Jun 25, 2001 at 09:40:56PM +0200, Martin Wilck wrote: > no one seems to have noticed Don't worry. The set of people who noticed was nonempty. On the other hand, in my tree: static inline unsigned int disk_index (kdev_t dev) { struct gendisk *g = get_gendisk(dev); return g ? (MINOR(dev) >> g->minor_shift) : 0; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
On 25 Jun 2001, John Fremlin wrote: > > Last year I had the idea of tracing the memory accesses of the system > to improve the VM - the traces could be used to test algorithms in > userspace. The difficulty is of course making all memory accesses > fault without destroying system performance. > > The following patch (i386 only) will dump all page faults to > /dev/biglog (you need devfs for this node to appear). If you echo 1 > > /proc/sys/vm/trace then *almost all* userspace memory accesses will > take a soft fault. Note that this is a bit suicidal at the moment > because of the staggeringly inefficient way its implemented, on my box > (K6-2 300MHz) only processes which do very little (e.g. /usr/bin/yes) > running at highest priority are able to print anything to the console. > > I think the best way would be to have only one valid l2 pte per > process. I'll have a go at doing that in a day or two unless someone > has a better idea? Linux Trace Toolkit (http://www.opersys.com/LTT) does that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
User space zero copy HOWTO?
Greetings! Is there any faq/sample code somewhere showing how to get zero copy tcp/ip with kernel 2.4, and what special hardware if any is required? Any information most appreciated. Kindly cc me directly. Take care, -- Camm Maguire[EMAIL PROTECTED] == "The earth is but one country, and mankind its citizens." -- Baha'u'llah - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ac17 "kernel BUG at slab.c:1244!"
Hello, At Fri, 22 Jun 2001 15:01:43 +, Gav wrote: > > This second one was immediately after rebooting, and hard locked at getty. > > kernel BUG at slab.c:1244! > invalid operand: > CPU:0 > EIP:0010:[] > EFLAGS: 00010082 > eax: 001b ebx: c187f788 ecx: 0001 edx: 2704 > esi: dfa5c000 edi: dfa5c9aa ebp: 00012800 esp: da801e2c > ds: 0018 es: 0018 ss: 0018 > Process mingetty (pid: 811, stackpage=da801000) > Stack: c023d5c5 04dc dfa5c000 1000 dfa5c9aa 0246 0007 0001 >dfa5c000 c0230b4a c030a2e0 0006 0406 c01931dd 0c3c >0007 0406 c0193e48 c198df88 0005 dfa5d000 > Call Trace: [] [] [] [] [] >[] [] [] [] [] > [] >[] [] > > Code: 0f 0b 5d 8b 6b 10 58 81 e5 00 04 00 00 74 4b b8 a5 c2 0f 17 > > >>EIP; c0126850<= > Trace; c0230b4a <_mmx_memcpy+fa/260> > Trace; c01931dd > Trace; c0193e48 > Trace; c0126d9c > Trace; c019485e > Trace; c012e932 > Trace; c010fd26 > Trace; c012eac6 > Trace; c012db40 > Trace; c012da69 > Trace; c0137c5a > Trace; c012dd43 > Trace; c0106ca7 <__up_wakeup+10fb/23f4> > Code; c0126850 > <_EIP>: > Code; c0126850<= >0: 0f 0b ud2a <= > Code; c0126852 >2: 5dpop%ebp > Code; c0126853 >3: 8b 6b 10 mov0x10(%ebx),%ebp > Code; c0126856 >6: 58pop%eax > Code; c0126857 >7: 81 e5 00 04 00 00 and$0x400,%ebp > Code; c012685d >d: 74 4b je 5a <_EIP+0x5a> c01268aa > > Code; c012685f >f: b8 a5 c2 0f 17mov$0x170fc2a5,%eax > > > 1 warning and 1 error issued. Results may not be reliable. > > This kernel was built with gcc 2.96 on an Athlon 1.33Ghz. > > Hope this is usefull, > I found a bug of release_mem() in tty_io.c and it may cause this oops. release_mem() frees the memory of tty_struct, but does not reset tty_files field of tty_struct. So, when fput() was called, it changes tty_files of already freed tty_struct. diff -r -u linux.org/drivers/char/tty_io.c linux/drivers/char/tty_io.c --- linux.org/drivers/char/tty_io.c Tue Jun 26 09:46:07 2001 +++ linux/drivers/char/tty_io.c Tue Jun 26 10:00:24 2001 @@ -1024,6 +1024,7 @@ } o_tty->magic = 0; (*o_tty->driver.refcount)--; + list_del(&o_tty->tty_files); free_tty_struct(o_tty); } @@ -1035,6 +1036,7 @@ } tty->magic = 0; (*tty->driver.refcount)--; + list_del(&tty->tty_files); free_tty_struct(tty); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Early flush: new, improved (updated)
This is an incremental update to the early flush patch. Changes: - flush_dirty_buffers returns sectors flushed instead of buffers flushed - submitted_sectors now treated as signed for robustness - misc cleanups To do: - Add retired_sectors, redefine queued_sectors in terms of submitted and retired. - Let the user set the bandwidth estimate through the bdflush_param interface or alternatively, attempt to measure the bandwidth automatically The first item needs a careful audit to make sure the two variables can't get out of sync, specifically, to ensure their mutual consistancy is properly protected by the io_request_lock. The retired_sectors value would be useful for automatic estimation of disk throughput but regardless of whether it gets used this way, it is slightly more efficient to derive queued_sectors than to maintain it explicitly, and this also eliminates the chance for it to get out of sync with submitted_sectors. I expect automatic estimation of disk throughput to be a tricky item. It's possible it would be better to leave it to be estimated in userspace via hdparm -t. The default settings for low_queued_goal and high_queued_goal are probably way too low, which would have the effect of limiting the rate at which the early flush proceeds. These are supposed to be set to the disk throughput in terms of sectors per 100 ms polling interval, and twice that, respectively. The low setting should not cause any performance degradation but it would probably eliminate the chance to see any significant throughput increase. Currently I'm working under the theory that the patch should never cause a performance loss and should sometimes show a performance gain. I'd appreciate hearing feedback from anyone who feels inspired to do some tests :-) As before, the patch is against 2.4.5. To apply: cd /your/source/tree patch b_flushtime = jiffies + bdf_prm.b_un.age_buffer; + bh->b_dirtytime = jiffies; refile_buffer(bh); } @@ -2524,12 +2524,18 @@ as all dirty buffers lives _only_ in the DIRTY lru list. As we never browse the LOCKED and CLEAN lru lists they are infact completly useless. */ -static int flush_dirty_buffers(int check_flushtime) + +static unsigned low_queued_goal = 200; +static unsigned high_queued_goal = 400; + +static int flush_dirty_buffers (int update) { struct buffer_head * bh, *next; - int flushed = 0, i; - - restart: + unsigned sectors_to_flush = bdf_prm.b_un.ndirty << 3; + unsigned youngest_to_flush = jiffies - bdf_prm.b_un.age_buffer; + int submitted = 0, i; + +restart: spin_lock(&lru_list_lock); bh = lru_list[BUF_DIRTY]; if (!bh) @@ -2544,22 +2550,18 @@ if (buffer_locked(bh)) continue; - if (check_flushtime) { - /* The dirty lru list is chronologically ordered so - if the current bh is not yet timed out, - then also all the following bhs - will be too young. */ - if (time_before(jiffies, bh->b_flushtime)) - goto out_unlock; - } else { - if (++flushed > bdf_prm.b_un.ndirty) + if (update) { + if (time_before (youngest_to_flush, bh->b_dirtytime)) + if (atomic_read (&queued_sectors) >= high_queued_goal) + goto out_unlock; + } else + if (sectors_to_flush >= sectors_to_flush) goto out_unlock; - } - /* OK, now we are committed to write it out. */ atomic_inc(&bh->b_count); spin_unlock(&lru_list_lock); ll_rw_block(WRITE, 1, &bh); + submitted += bh->b_size >> 9; atomic_dec(&bh->b_count); if (current->need_resched) @@ -2569,7 +2571,12 @@ out_unlock: spin_unlock(&lru_list_lock); - return flushed; +#ifdef DEBUG + if (update) + printk("updated %i at %lu, %u queued\n", + submitted, jiffies, atomic_read (&queued_sectors)); +#endif + return submitted; } DECLARE_WAIT_QUEUE_HEAD(bdflush_wait); @@ -2717,7 +2724,7 @@ int kupdate(void *sem) { struct task_struct * tsk = current; - int interval; + int submitted0 = atomic_read (&submitted_sectors), countdown = 0; tsk->session = 1; tsk->pgrp = 1; @@ -2733,11 +2740,12 @@ up((struct semaphore *)sem); for (;;) { - /* update interval */ - interval = bdf_prm.b_un.interval; - if (interval) { + unsigned sync_interval = bdf_prm.b_un.interval; + unsigned poll_interval = HZ/10; + +
Re: GCC3.0 Produce REALLY slower code!
Well, I haven't gone and looked at every line of assembler, but I'd bet this is a hasty characterization. According to someones recent count there are around 144000 lines of assembler in the 2.4.2 kernel. It seems to me you'd have to jump through a lot of hoops to test this compiler. Then there's the other question: Why should we test a compiler that seems to be quite proprietary? The invitation indicates it uses FLexLM to manage the license. I somehow doubt Linus or just about anyone else is going to care, save for the folks in Intel, who can do this for themselves just fine. But, hey, I won't try and stop you. Have fun. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Difference between get_free_page() and page_cache_alloc() ?
Never mind.. I figured it out. __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Difference between get_free_page() and page_cache_alloc() ?
get_free_page() returns a pointer to a page while page_cache_alloc returns a pointer to a page struct. Is page_cache_alloc more efficient than get_free_page()? Also, does get_free_page returns a pointer to a contiguous block of physical memory? Thanks __ Get your own FREE, personal Netscape Webmail account today at http://webmail.netscape.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac18
Alan Cox wrote: >>>oLave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima) >>> probe for longer on cmd timeout >>> >> >> >>Please, people... S is siemens, not seconds. Seconds is "s" (lower >>case.) The rule is simple: units named after people have their >>symbols, but not their names, capitalized. >> > > The day everyone learns to spell weird properly I'll learn to get seconds right > - deal ? > You mean people don't know how to spell weird? That's... weird... -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Hang with usb scanner...2.4.5-acx
HI, I got scanner epson perfection 640u. I am not sure if it is a bug or I have to do like that. Basically I have to compile scanner support as module and uhci as well. Whenever I need to scan, just turn on, modprobe ...; it is fine. When no need, remove modules and turn off. BUT if i compile built in to th kernel. the system hang in sush cases: - turn on pc, start everything, then turn on scanner - turn on scanner then turn on pc start everything, scanner works ; now turn off scanner No messages in /var/log ; just hang all key board wont work, can not login from remote, ; have to unplug the power thanks, = S.KIEU _ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: supermount
--- Sam Halliday <[EMAIL PROTECTED]> wrote: > This email was delivered to you by The Free > Internet, > a Business Online Group company. > http://www.thefreeinternet.net I totally aggree, supermount is nice features and it should be integrated into the main kernel stream (just my HO) > --- > hello, > i am fairly new to linux, i need it's fast > number crunching powers > for my research... and i have only recently begun to > have a look at the > kernel (i believe every workman should know his > tools). but i have > noticed that supermount is not a standard part of > the project, is there > any reason why this is? is it due to man power? i > would have been less > shocked by the absense of other features in the > > radio support, supermount seems to me to be > essential in any operating > system. > i apologise if this is a very silly question or > if i have posted > this question in the wrong place, but please excuse > me, im new to this > whole world. > > and keep up the good work, i wish i knew more about > the whole thing so i > could contribute something. > > Sam, Ireland > > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ = S.KIEU _ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GCC3.0 Produce REALLY slower code!
There is not so much code in asm, so it's easy to patch code the most reasonable method is to write parsing program for that Best regards, Alexander mailto:[EMAIL PROTECTED] -- Let's start the war, said Meggy -- - Original Message - From: "Hacksaw" <[EMAIL PROTECTED]> To: "Alexander V. Bilichenko" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, June 26, 2001 3:30 AM Subject: Re: GCC3.0 Produce REALLY slower code! > >Here is link to Intel C compiler, that provide really faster code. > > > >http://developer.intel.com/software/products/compilers/linuxbeta.htm > > A quote from the site: > > * Not all of the GNU C language extensions, including the GNU inline assembly > format, are currently supported and, due to this, one cannot build the Linux > kernel with the beta release of the Intel compilers and the initial product > release. > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux and system area networks
> OK, how about an Infiniband network with a TCP/IP gateway at the edge? > Have we thought about how Linux servers should use the gateway to talk > to internet hosts? Surely there's no point in running TCP/IP inside > the Infiniband network, so there needs to be some concept of "socket > over Infiniband." So write the library, it shouldnt need the kernel involved, and you can take over AF_INET socket syscalls with an LD_PRELOAD so it can be transparent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux and system area networks
> a properly written host based stack works much better in > the face of a changing environment: Faster CPUs, new CPUs > (IA-64), new network protocols (ECN). Besides, it is easy > to "accelerate" a bad network stack, but try to outdo a > well done stack. Putting the stack partly in user spacd can sometimes be a benefit. Linux 8086 does this to cut down kernel size for example ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The Joy of Forking
Fork nothing, stop taking stupidity. The kernel SOURCES may be 26MB but that does NOT mean you have to use every driver! Shawn. On Mon, 25 Jun 2001, Rick Hohensee wrote: > > > > Rick Hohensee <[EMAIL PROTECTED]> said: > > > 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has > > > already stuck his tippy-toe is that pool, and his toe is fine. > > > > Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave > > Miller, or any of the arch maintainers. Alan has said several times that he > > will sync up with Linus, and he still stages patches upwards. Alan doesn't > > like the "all shall be devfs" ukase (and neither do I, BTW), and will > > maintain non-devfs systems for the time being. > > > > I do see the merit of some kind of devfs, but there still is a lot of stuff > > that needs a more reasonable solution, so no thanks for now. > > I've had quite a good two rants lately and will be happy to get on to > other things for now. My point is to think of devfs and dozens of other > things in the context of more than one Linux. Just a thought. > > Rick Hohensee > www.clienux.com > > > -- > > Horst von Brand [EMAIL PROTECTED] > > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac18
> > o Lave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima) > > probe for longer on cmd timeout > > > > Please, people... S is siemens, not seconds. Seconds is "s" (lower > case.) The rule is simple: units named after people have their > symbols, but not their names, capitalized. The day everyone learns to spell weird properly I'll learn to get seconds right - deal ? Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The Joy of Forking
> > Rick Hohensee <[EMAIL PROTECTED]> said: > > 2.4.5 is 26 meg now. It's time to consider forking the kernel. Alan has > > already stuck his tippy-toe is that pool, and his toe is fine. > > Stop that nonsense. Alan Cox has _not_ forked anything, neither has Dave > Miller, or any of the arch maintainers. Alan has said several times that he > will sync up with Linus, and he still stages patches upwards. Alan doesn't > like the "all shall be devfs" ukase (and neither do I, BTW), and will > maintain non-devfs systems for the time being. > > I do see the merit of some kind of devfs, but there still is a lot of stuff > that needs a more reasonable solution, so no thanks for now. I've had quite a good two rants lately and will be happy to get on to other things for now. My point is to think of devfs and dozens of other things in the context of more than one Linux. Just a thought. Rick Hohensee www.clienux.com > -- > Horst von Brand [EMAIL PROTECTED] > Casilla 9G, Vin~a del Mar, Chile +56 32 672616 > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GCC3.0 Produce REALLY slower code!
>Here is link to Intel C compiler, that provide really faster code. > >http://developer.intel.com/software/products/compilers/linuxbeta.htm A quote from the site: * Not all of the GNU C language extensions, including the GNU inline assembly format, are currently supported and, due to this, one cannot build the Linux kernel with the beta release of the Intel compilers and the initial product release. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-2.4.5-ac16/17/18: floppy driver problem with lilo boot disks?
Hello, I mount my bootdisk (minix filesystem) with "mount /dev/fd0 /mnt" and copy my new compiled kernel to it. After that I do a "lilo -v -C /mnt/lilo.conf". All following commands which are floppy related (filesystem) fall into the D state. Load goes up by 100 for every D state process. ls /mnt umount /mnt sync SunWave1#cat /proc/version Linux version 2.4.5-ac16 (root@SunWave1) (gcc version 2.95.2 19991024 (release)) #1 Wed Jun 20 18:01:34 CEST 2001 SunWave1#ps aux root 1039 0.0 0.0 1404 64 pts/1D16:24 0:00 umount /mnt nuetzel 1108 0.1 0.1 1412 500 pts/5D16:28 0:00 sync Even "reboot" do nothing. I have to push the reset button. Luckily I have ReiserFS running and only some seconds to wait during bootup for replay the transaction logs. But mount/umount other disk partitions works as expected. Thanks, Dieter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux and system area networks
> "Pete" == Pete Zaitcev <[EMAIL PROTECTED]> writes: Roland> The rough idea is that WSD is a new user space library Roland> that looks at sockets calls and decides if they have to go Roland> through the usual kernel network stack, or if they can be Roland> handed off to a "SAN service provider" which bypasses the Roland> network stack and uses hardware reliable transport and Roland> possibly RDMA. Pete> That can be done in Linux just as easily, using same DLLs Pete> (they are called .so for "shared object"). If you look at Pete> Ashok Raj's Infi presentation, you may discern "user-level Pete> sockets", if you look hard enough. I invite you to try, if Pete> errors of others did not teach you anything. I think you misunderstood the point. Microsoft is providing this WSD DLL as a standard part of W2K now. This means that hardware vendors just have to write a SAN service provider, and all Winsock-using applications benefit transparently. No matter how good your TCP/IP implementation is, you still lose (especially in latency) compared to using reliable hardware transport. Oracle-with-VI and DAFS-vs-NFS benchmarks show this quite clearly. Linux has nothing to compare to Winsock Direct. I agree, one could put an equivalent in glibc, or one could take advantage of Linux's relatively low system call latency and put something in the kernel. The unfortunate consequence of this is that SAN (system area network) hardware vendors are not going to support Linux very well. BTW, do you have a pointer to Ashok Raj's presentation? Roland> This means that all applications that use Winsock benefit Roland> from the advanced network hardware. Also, it means that Roland> Windows is much easier for hardware vendors to support Roland> than other OSes. For example, Alacritech's TCP/IP offload Roland> NIC only works under Windows. Microsoft is also including Roland> Infiniband support in Windows XP and Windows 2002. Pete> IMHO, Alacritech is about to join scores and scores of Pete> vendors who tried that before. Customers understand very Pete> soon that a properly written host based stack works much Pete> better in the face of a changing environment: Faster CPUs, Pete> new CPUs (IA-64), new network protocols (ECN). Besides, it Pete> is easy to "accelerate" a bad network stack, but try to Pete> outdo a well done stack. OK, how about an Infiniband network with a TCP/IP gateway at the edge? Have we thought about how Linux servers should use the gateway to talk to internet hosts? Surely there's no point in running TCP/IP inside the Infiniband network, so there needs to be some concept of "socket over Infiniband." Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac18
On 25 Jun 2001, H. Peter Anvin wrote: > Date: 25 Jun 2001 14:08:26 -0700 > From: H. Peter Anvin <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Linux 2.4.5-ac18 > > Followup to: <[EMAIL PROTECTED]> > By author:Alan Cox <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > o Lave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima) > > probe for longer on cmd timeout > > > > Please, people... S is siemens, not seconds. Seconds is "s" (lower > case.) The rule is simple: units named after people have their > symbols, but not their names, capitalized. ok who was Mr/Mrs Byte? sorry couldn't resist :-) David Lang > Microseconds are written µs, or if the µ symbol is unavailable, us. > > Sorry, this one grates on me... > > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.5 and gcc v3 final
On Sun, Jun 24, 2001 at 01:33:51PM -0400, Horst von Brand wrote: > What gcc objects to is stuff like: > >"This is a nice long string > that just goes on > and on\n" > > which is illegal in C AFAIU. It does not object to: > >"This long string" >"spans several lines, " >"but legally.\n" But the first example contains three newlines, the second just one. A thing to keep in mind when going around fixing these multi line strings, explicit newlines have to be added. -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
More module conversion...
In my quest to convert a module from 2.2 to 2.4, I came across a nice oops (it actually was from their code that I thought I didn't have to touch...). The oops comes when trying to access address 0xd2000, which the code for this robot controller has hardcoded as its "BASE_ADDR" Were the base addresses for io cards moved between 2.2 and 2.4? * Please cc me since I'm not currently subscribed. Thanks, --James Lamanna ksymoops 2.4.0 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux-2.4.5/System.map (specified) Warning (compare_maps): ksyms_base symbol __VERSIONED_SYMBOL(shmem_file_setup) not found in System.map. Ignoring ksyms_base entry Jun 25 15:10:08 martel kernel: Unable to handle kernel paging request at virtual address 000d2000 Jun 25 15:10:08 martel kernel: c8853cc0 Jun 25 15:10:08 martel kernel: *pde = Jun 25 15:10:08 martel kernel: Oops: Jun 25 15:10:08 martel kernel: CPU:0 Jun 25 15:10:08 martel kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Jun 25 15:10:08 martel kernel: EFLAGS: 00010286 Jun 25 15:10:08 martel kernel: eax: 000d2000 ebx: 00fd ecx: c748e000 edx: c0244b64 Jun 25 15:10:08 martel kernel: esi: edi: ebp: c8854780 esp: c6a11ef0 Jun 25 15:10:08 martel kernel: ds: 0018 es: 0018 ss: 0018 Jun 25 15:10:08 martel kernel: Process insmod (pid: 1071, stackpage=c6a11000) Jun 25 15:10:08 martel kernel: Stack: 0001 c028853c 0019 00fd 0806e918 c8853f66 Jun 25 15:10:08 martel kernel:c8854780 00fd c8854640 c8853000 c8853000 c0111a05 Jun 25 15:10:08 martel kernel: c63a8000 16a0 c63a9000 0060 ffea 0005 c6b25e00 Jun 25 15:10:08 martel kernel: Call Trace: [] [] [] [] [] [] [] Jun 25 15:10:08 martel kernel:[] [] Jun 25 15:10:08 martel kernel: Code: 0f b6 34 07 89 f2 80 fa ff 74 08 84 d2 0f 85 09 01 00 00 47 >>EIP; c8853cc0 <[i200m]i200m_probe+20/168> <= Trace; c8853f66 <[i200m]init_module+e2/138> Trace; c8854780 <[i200m]__module_kernel_version+0/0> Trace; c8854640 <[i200m]i200m_fops+0/5f> Trace; c8853000 <[wvlan_cs]__module_parm_station_name+12e98/12ef8> Trace; c8853000 <[wvlan_cs]__module_parm_station_name+12e98/12ef8> Trace; c0111a05 Trace; c883a000 <[ds].data.end+15c1/1621> Trace; c8853060 <[i200m]i200m_boot_command+0/d4> Trace; c0106c4b Code; c8853cc0 <[i200m]i200m_probe+20/168> <_EIP>: Code; c8853cc0 <[i200m]i200m_probe+20/168> <= 0: 0f b6 34 07 movzbl (%edi,%eax,1),%esi <= Code; c8853cc4 <[i200m]i200m_probe+24/168> 4: 89 f2 mov%esi,%edx Code; c8853cc6 <[i200m]i200m_probe+26/168> 6: 80 fa ff cmp$0xff,%dl Code; c8853cc9 <[i200m]i200m_probe+29/168> 9: 74 08 je 13 <_EIP+0x13> c8853cd3 <[i200m]i200m_probe+33/168> Code; c8853ccb <[i200m]i200m_probe+2b/168> b: 84 d2 test %dl,%dl Code; c8853ccd <[i200m]i200m_probe+2d/168> d: 0f 85 09 01 00 00 jne11c <_EIP+0x11c> c8853ddc <[i200m]i200m_probe+13c/168> Code; c8853cd3 <[i200m]i200m_probe+33/168> 13: 47inc%edi 1 warning issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux and system area networks
> I'd like to find out if anyone has thought about how Linux will handle > some of the new network technologies people are starting to push. > Specifically I'm talking about "System Area Networks," that is, things > like Infiniband, as well as TCP/IP offload. Infiniband is doing relatively well, as much as anything can with Intel at the helm (see "Itanic"). This has nothing to do with TCP/IP offload, which is an extremely stupid idea. The whole thing stems from a desire by vendors to sell "smart" (== very expensive) NICs. RDMA in Infiniband is, in my view, a little more than traditional DMA in any other advanced server I/O bus. Sun UPA is packetized, for instance. > The rough idea is that WSD is a new user space library that looks at > sockets calls and decides if they have to go through the usual kernel > network stack, or if they can be handed off to a "SAN service > provider" which bypasses the network stack and uses hardware reliable > transport and possibly RDMA. That can be done in Linux just as easily, using same DLLs (they are called .so for "shared object"). If you look at Ashok Raj's Infi presentation, you may discern "user-level sockets", if you look hard enough. I invite you to try, if errors of others did not teach you anything. > This means that all applications that use Winsock benefit from the > advanced network hardware. Also, it means that Windows is much easier > for hardware vendors to support than other OSes. For example, > Alacritech's TCP/IP offload NIC only works under Windows. Microsoft > is also including Infiniband support in Windows XP and Windows 2002. IMHO, Alacritech is about to join scores and scores of vendors who tried that before. Customers understand very soon that a properly written host based stack works much better in the face of a changing environment: Faster CPUs, new CPUs (IA-64), new network protocols (ECN). Besides, it is easy to "accelerate" a bad network stack, but try to outdo a well done stack. > So I guess my question is whether anyone has started thinking about > the architectural changes needed to make System Area Networking and > TCP/IP offload easier under Linux. Pretty much zero-copy that DaveM and Co. do addresses this. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [UPDATE] Directory index for ext2
On Monday 25 June 2001 21:51, Andreas Dilger wrote: > Daniel writes: > > > > On Wednesday 20 June 2001 16:59, Tony Gale wrote: > > > > > The main problem I have with this is that e2fsck doesn't know how > > > > > to deal with it - at least I haven't found a version that will. > > > > > This makes it rather difficult to use, especially for your root fs. > > > > Sure, if your root partition is expendable, by all means go ahead. Ted > > has already offered to start the required changes to e2fsck, which > > reminds me, I have to send the promised docs. For now, just use normal > > fsck and it will (in theory) turn the directory indexes back into normal > > file blocks, and have no effect on inodes. > > This is only true without the COMPAT_DIR_INDEX flag. Since e2fsck _needs_ > to know about every filesystem feature, it will (correctly) refuse to touch > such a system for now. You could "tune2fs -O ^FEATURE_C4 /dev/hdX" to > turn of the COMPAT_DIR_INDEX flag and let e2fsck go to town. That will > break all of the directory indexes, I believe. This is what he wants, a workaround so he can fsck. However, the above command (on version 1.2-WIP) just gives me: Invalid filesystem option set: ^FEATURE_C4 Maybe he should just edit the source so it doesn't set the superblock flag for now. BTW, there doesn't seem to be a --version command in tune2fs. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
oh ;) I never noticed that info before, then again 2 hours of sleep might be the cause :) On 25 Jun 2001, H. Peter Anvin wrote: > Followup to: <[EMAIL PROTECTED]> > By author:Shawn Starr <[EMAIL PROTECTED]> > In newsgroup: linux.dev.kernel > > > > Is this a bug or something thats undocumented somewhere? > > > > dT > > and > > drwSrwSrwT > > > > are these special bits? I'm not aware of +S and +T > > > > It's neither a bug nor undocumented. > > "info ls" would have told you the following: > > The permissions listed are similar to symbolic mode > specifications > (*note Symbolic Modes::.). But `ls' combines multiple bits into > the third character of each set of permissions as follows: > `s' > If the setuid or setgid bit and the corresponding executable > bit are both set. > > `S' > If the setuid or setgid bit is set but the corresponding > executable bit is not set. > > `t' > If the sticky bit and the other-executable bit are both set. > > `T' > If the sticky bit is set but the other-executable bit is not > set. > > `x' > If the executable bit is set and none of the above apply. > > `-' > Otherwise. > > -hpa > -- > <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! > "Unix gives you enough rope to shoot yourself in the foot." > http://www.zytor.com/~hpa/puzzle.txt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] rio500 devfs support
I was thinking of doing some similar updates this evening after work. Darn it... now I have to find something else to do! :-) Going by this morning's comments from Richard Gooch, it sounds like the if (rio->devfs == NULL) dbg("probe_rio: device node registration failed"); part should probably be removed... it looks good to me otherwise, tho. I'll try it out tonight and post the results. Cheers! On Mon, Jun 25, 2001 at 10:35:21AM -0700, Greg KH wrote: > Here's a small change that makes the node a child of the usb devfs > entry. It also enables the node to only be present when the device is > actually present. The patch is against 2.4.6-pre5. > > thanks, > > greg k-h PGP signature
Re: EXT2 Filesystem permissions (bug)?
Those are normal unix permissions, and you can use them on every kind of Unix FS, (at less i saw them on jfs, hfs, vxfs, xfs, reiserfs, ext2, ufs). S is suid and sgid without execution bit. T is stiky bit without any execution bit. (I hope my english is correct) Luigi On Mon, 25 Jun 2001, Shawn Starr wrote: > > Is this a bug or something thats undocumented somewhere? > > dT > and > drwSrwSrwT > > are these special bits? I'm not aware of +S and +T > > Shawn. > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
Shawn Star writes: > Is this a bug or something thats undocumented somewhere? > > dT > and > drwSrwSrwT > > are these special bits? I'm not aware of +S and +T ---S-- = setuid (normally shows up as "s" if "x" is also set) --S--- = setgid (normally shows up as "s" if "x" is also set) -T = sticky bit (prevents non-owner from deleting a file in world-writable directory like /tmp) See chmod(1) for this info. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EXT2 Filesystem permissions (bug)?
Followup to: <[EMAIL PROTECTED]> By author:Shawn Starr <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > > Is this a bug or something thats undocumented somewhere? > > dT > and > drwSrwSrwT > > are these special bits? I'm not aware of +S and +T > It's neither a bug nor undocumented. "info ls" would have told you the following: The permissions listed are similar to symbolic mode specifications (*note Symbolic Modes::.). But `ls' combines multiple bits into the third character of each set of permissions as follows: `s' If the setuid or setgid bit and the corresponding executable bit are both set. `S' If the setuid or setgid bit is set but the corresponding executable bit is not set. `t' If the sticky bit and the other-executable bit are both set. `T' If the sticky bit is set but the other-executable bit is not set. `x' If the executable bit is set and none of the above apply. `-' Otherwise. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
EXT2 Filesystem permissions (bug)?
Is this a bug or something thats undocumented somewhere? dT and drwSrwSrwT are these special bits? I'm not aware of +S and +T Shawn. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.6pre iptables masquerading seems to kill eth0
On Fri, Jun 22, 2001 at 09:20:26AM +0200, Helge Hafting wrote: > Thomas Weber wrote: > > > > I'm on 2.4.6pre3 + freeswan/ipsec on my gateway now for 5 days. > > It's an old 486/66 32MB with several isdn links, a dsl uplink (with > > iptables masquerading) behind a ne2k clone and a 3c509 to the inside network. > > no problems at all with the interfaces (all compiled as modules). > > Nice to know it works for you. The troubled machine is a dual celeron, > so it could be some sort of SMP problem. I am trying pre5 > to see if it is better, I'll probably know in a few days. since i just read another report on the list I checked again and it seems like i messed it up: you were talking about the 3c905, but I have a 3c509 (ISA) card. I should have known, it's not the first time i mixed them up :( Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sizeof problem in kernel modules
Alan Shutko <[EMAIL PROTECTED]> said: > One more tidbit: ISO/IEC 9899:1990 3.14 > > 3.14 object: A region of data storage in the execution environment, > the contents of which can represent values. Except for > bit-fields, objects are composed of contiguous sequences of one or > more bytes, the number, order and encoding of which are either > explicitely specified or implementation-defined. > > This would specifically prohibit separating any part of a structure > from the rest. It just prohibits separating bytes, not subobjects. I.e., everything can be handled as an array of bytes (of the appropiate length, as given by sizeof()) -- Dr. Horst H. von BrandUsuario #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
Rik van Riel <[EMAIL PROTECTED]> writes: > On 25 Jun 2001, John Fremlin wrote: > > > Last year I had the idea of tracing the memory accesses of the > > system to improve the VM - the traces could be used to test > > algorithms in userspace. The difficulty is of course making all > > memory accesses fault without destroying system performance. > > Sounds like a cool idea. One thing you should keep in mind though > is to gather traces of the WHOLE SYSTEM and not of individual > applications. In the current patch all pagefaults are recorded from all sources. I'd like to be able to catch read(2) and write(2) (buffer cache stuff) as well but I don't know how . . . . > There has to be a way to balance the eviction of pages from > applications against those of other applications. Of course! It is important not to regard each thread group as an independent entity IMHO (had a big old argument about this). [...] -- http://ape.n3.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac18
Followup to: <[EMAIL PROTECTED]> By author:Alan Cox <[EMAIL PROTECTED]> In newsgroup: linux.dev.kernel > o Lave 1uS gaps in the eepro100 cmd probe, and(Masaru Kawashima) > probe for longer on cmd timeout Please, people... S is siemens, not seconds. Seconds is "s" (lower case.) The rule is simple: units named after people have their symbols, but not their names, capitalized. Microseconds are written µs, or if the µ symbol is unavailable, us. Sorry, this one grates on me... -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] skb destructor enhancement idea
Here is a patch against 2.4.6pre5 that implements a gneric, 'chainable' destructor mechanism for sk_buff structures. It allows for an arbitrary number of ordered destructor calls for skbs. We are currently using this change in a low-level packet monitoring module so we can allocate our own packet memory and get called back when the skb is done moving through the stack. It seems like it should be useful to allow network drivers to implement their own device-specific memory management and thus reduce mem copying overhead, too. Any driver people want to try it out and see if they can make their driver use it to reduce copying? Any comments on the idea in general? -- -Will :: AD6XL :: http://tyranny.egregious.net/~will/ Orton :: finger [EMAIL PROTECTED] for GPG public key diff -ur linux-246p5-clean/include/linux/skbuff.h linux/include/linux/skbuff.h --- linux-246p5-clean/include/linux/skbuff.hFri May 25 18:01:43 2001 +++ linux/include/linux/skbuff.hMon Jun 25 12:23:49 2001 @@ -25,6 +25,7 @@ #include #include #include +#include #define HAVE_ALLOC_SKB /* For the drivers to know */ #define HAVE_ALIGNABLE_SKB /* Ditto 8)*/ @@ -114,6 +115,18 @@ __u16 size; }; +struct sk_buff_dest { + struct sk_buff_dest *next; + void (*destructor)(void *); + void *context; +}; + +struct sk_buff_dest_pool { + struct sk_buff_dest *head; + spinlock_t lock; + kmem_cache_t*cache; +}; + /* This data is invariant across clones and lives at * the end of the header data, ie. at skb->end. */ @@ -191,7 +204,7 @@ unsigned char *tail; /* Tail pointer */ unsigned char *end; /* End pointer */ - void(*destructor)(struct sk_buff *);/* Destruct function */ + struct sk_buff_dest_pooldestructor; #ifdef CONFIG_NETFILTER /* Can be used for communication between hooks. */ unsigned long nfmark; @@ -245,6 +258,78 @@ /* Internal */ #define skb_shinfo(SKB)((struct skb_shared_info *)((SKB)->end)) +/* SKB destructor stuff */ +extern unsigned int skbd_stat_add_head; +extern unsigned int skbd_stat_add_dest; +extern unsigned int skbd_stat_alloc; +extern unsigned int skbd_stat_call_dest; +extern unsigned int skbd_stat_maybe_call_dest; + +extern struct sk_buff_dest_pool sk_buff_dest_free_pool; + +static inline void skbd_add_head(struct sk_buff_dest_pool *pool, +struct sk_buff_dest *newnode) +{ + skbd_stat_add_head++; + newnode->next = pool->head; + pool->head = newnode; +} + +static inline void skbd_remove_head(struct sk_buff_dest_pool *pool, + struct sk_buff_dest **rmnode) +{ + if ((*rmnode = pool->head) != NULL) + pool->head = pool->head->next; +} + + +static inline int skb_add_dest(struct sk_buff *skb, void (*destructor)(void *), + void *context, unsigned long gfp_mask) +{ + unsigned long flags; + struct sk_buff_dest *skbd; + + skbd_stat_add_dest++; + + spin_lock_irqsave(&sk_buff_dest_free_pool.lock, flags); + skbd_remove_head(&sk_buff_dest_free_pool, &skbd); + spin_unlock_irqrestore(&sk_buff_dest_free_pool.lock, flags); + + if (!skbd) { + skbd_stat_alloc++; + skbd = kmem_cache_alloc( sk_buff_dest_free_pool.cache, gfp_mask); + if (!skbd) { + printk(" out of memory allocating skbd\n"); + return 1; + } + } + + skbd->destructor = destructor; + skbd->context = context; + skbd_add_head(&skb->destructor, skbd); + return 0; +} + + + +static inline void skb_call_dest(struct sk_buff *skb) +{ + unsigned long flags; + struct sk_buff_dest *skbd; + + skbd_stat_maybe_call_dest++; + skbd_remove_head(&skb->destructor, &skbd); + + while (skbd) { + skbd_stat_call_dest++; + skbd->destructor(skbd->context); + + spin_lock_irqsave(&sk_buff_dest_free_pool.lock, flags); + skbd_add_head(&sk_buff_dest_free_pool, skbd); + spin_unlock_irqrestore(&sk_buff_dest_free_pool.lock, flags); + + skbd_remove_head(&skb->destructor, &skbd); + } +} + /** * skb_queue_empty - check if a queue is empty * @list: queue head @@ -971,9 +1056,7 @@ static inline void skb_orphan(struct sk_buff *skb) { - if (skb->destructor) - skb->destructor(skb); - skb->destructor = NULL; + skb_call_dest(skb); skb->sk = NUL
Re: Oops in iput
Hi, On Mon, Jun 25, 2001 at 08:16:12PM +0200, Florian Lohoff wrote: > > oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) The ide-udma patches for 2.2 haven't had nearly the testing of the 2.4 ones, and simply can't be trusted as a baseline for debugging other code. Can you reproduce this problem without them applied? The oops here is a networking oops on the face of it, and I wouldn't expect to see that on 2.2 unless something was corrupting memory. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: AMD thunderbird oops
On Mon, 25 Jun 2001, Alan Cox wrote: > Random oopses normally indicate faulty board cpu or ram (and the fault may > even just be overheating or dimms not in the sockets cleanly). I doubt its > the board design or model that is the problem, you probably jut have a faulty > component somewhere if its oopsing randomly even during installs and stuff Ive found a number of problems can be traced to power supply problems, the board providing a bit of under voltage. Manually adjusting CPU voltage a notch or two up has fixed many a board for me. Also manually adjusting SDRAM drive strength can help, BIOS sometimes gets this wrong. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VIA Southbridge bug (Was: Crash on boot (2.4.5))
I'd be interested in testing any fixes for the VIA Southbridge chip. I have an ASUS A7V133. I was having problems with the IDE controller, but I've switched to the on-board Promise IDE and it works fine. I couldn't get rid of the DMA timeout errors with my VIA vt82c686b, even with the latest patches. I even completely disabled DMA (through .config options) and I although I didn't get DMA timeout errors anymore, everything still came to a halt under heavy disk usage. Would it be a good idea to form a small mailing list of people with VIA chipsets (vt82c686b only)? Then perhaps we could communicate with Vojtech more easily, and the VIA southbridge problems might end a little quicker. It seems like there are a bunch of people still having the VIA problems. David Grant - Original Message - From: "Andy Ward" <[EMAIL PROTECTED]> To: "Steven Walter" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, June 25, 2001 12:57 PM Subject: RE: VIA Southbridge bug (Was: Crash on boot (2.4.5)) > I'd love to help out with testing (alas, my kernel coding skills aren't > up to fixing this kind of problem). Heck, if it trashes my linux > install, no biggie... I've got it ghosted to an image elsewhere... > > Anyone wanting to work on this just drop me an email. > > -- andyw > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
Hi again, some old brain-cells got excited with the "good-ol-days" and other names have surfaced like "Superbrain","Sirius" and "Apricot".Sirius was Victor in the USA. If you go done the so-called IBM compatible route then the nearly compatible nightmares will arise and haunt you, your lucky if the scars have faded!! I learnt my computing on a PDP8/E with papertape punch/reader, RALF, Fortran II, then later 2.4Mb removable cartridges (RK05 I think). toggling in the bootstrap improved your concentration. Much later you could get a single chip(?) version of this in a wee knee sized box. One summer job was working on a PDP15 analog computer alongside an 11/20 with DECTAPE, trying to compute missile firing angles. [A simple version of Pres Bush's starwars shield]. -- Andrew Smith in Edinburgh,Scotland On 25 Jun 2001, Kai Henningsen wrote: > [EMAIL PROTECTED] (Rob Landley) wrote on 24.06.01 in ><[EMAIL PROTECTED]>: > > > Now if somebody here could just point me to a decent reference on A/UX - > > Apple's mid-80's version of Unix (for the early macintosh, I believe...) > > http://www.google.com/search?q=%22%2ba/ux%22 > > Usually a good idea. > > > > Also, you probably want to look at RFC 2235. > > MfG Kai > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))
I'd love to help out with testing (alas, my kernel coding skills aren't up to fixing this kind of problem). Heck, if it trashes my linux install, no biggie... I've got it ghosted to an image elsewhere... Anyone wanting to work on this just drop me an email. -- andyw -Original Message- From: Steven Walter [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 1:33 AM To: Andy Ward Cc: [EMAIL PROTECTED] Subject: VIA Southbridge bug (Was: Crash on boot (2.4.5)) Great, glad to here it. Who (if anyone) is still attempting to unravel the puzzle of the Via southbridge bug? You, Andy, should try and get in touch with them and help debug this thing, if you're up to it. On Mon, Jun 25, 2001 at 01:17:57AM -0500, Andy Ward wrote: > Well, I have tried your suggestion, and it works beautifully... The > only change I made was to the cpu type (to 686), and everything *just* > works now... Thanks, all!!! > > > From the look of things, you're being bitten by the VIA southbridge > > problem. As I've gathered, its some sort of interaction with that chip > > and the 3DNow! fast copy routines the kernel uses. > > > > If you compile the kernel for a 686, does the problem go away? What > > about 586 or lower? If so, I believe there are some people working on > > finding common aspects of the hardware that experience this problem, > > though I don't remember who. You should get in contact with them, or > > they might get into contact with you. > > > > Good luck on working this out. > > -- > > -Steven > > In a time of universal deceit, telling the truth is a revolutionary act. > > -- George Orwell -- -Steven In a time of universal deceit, telling the truth is a revolutionary act. -- George Orwell - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
On Mon, Jun 25, 2001 at 10:17:09AM -0400, Rob Landley wrote: > On Monday 25 June 2001 11:13, you wrote: > > 1937 claude shannon A Symbolic Analysis of Relay and Switching Circuits," > > > > 1948 claude shannon A mathematical theory of information. > > > > without those you're kind in trouble on the computing front... [snip] > This was the dude who decided to apply a binary and boolean approach to > electronic computation, right? I KNOW I've read some stuff about him... late > last year? Yes, but the latter paper was the real milestone. This was the guy who actually defined what information *is*, and found out the upper limits of communication rates on a given channel. This was the guy who laid the fundaments of the information theory. Without information theory no compression, reliable transmission, reliable storage, crypthography, etc. Erik [who works in an information theory group] -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: VIA Southbridge bug (Was: Crash on boot (2.4.5))
oh really? I have my memory timings set to 133/cas2/6-4-4-4. One wonders... *ponder* I have noticed some general flakyness (hard to pin down) on the system, though... random program crashes, minor visual corruption in X (which fixes itself when you move things around), etc... Anyone want to take a swing at that? -- andyw -Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Monday, June 25, 2001 2:07 AM To: Steven Walter Cc: Andy Ward; [EMAIL PROTECTED] Subject: Re: VIA Southbridge bug (Was: Crash on boot (2.4.5)) > Great, glad to here it. Who (if anyone) is still attempting to unravel > the puzzle of the Via southbridge bug? You, Andy, should try and get in > touch with them and help debug this thing, if you're up to it. The IWILL problem seems unrelated. Its the board that more than others people report fails totally when streaming memory copies using movntq instructions. The Athlon optimised kernel places pretty much the absolute maximum load possible on the memory bus. Several people have reported that machines that are otherwise stable on the bios fast options require the proper conservative settings to be stable with the Athlon optimisations Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
On Monday 25 June 2001 13:14, [EMAIL PROTECTED] wrote: > Hi, > > If you're really keen on old mags and manuals I'll go up to attic and look > around. I know there are old SCO Xenix & TCP/IP, as well as Byte and Dr > Dobbs > Ooh! Yes! Very much so. Thanks, Rob The mailing list for this discussion is: http://lists.sourceforge.net/lists/listinfo/penguicon-comphist - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Ext2-devel] Re: [UPDATE] Directory index for ext2
Daniel writes: > > > On Wednesday 20 June 2001 16:59, Tony Gale wrote: > > > > The main problem I have with this is that e2fsck doesn't know how to > > > > deal with it - at least I haven't found a version that will. This makes > > > > it rather difficult to use, especially for your root fs. > > Sure, if your root partition is expendable, by all means go ahead. Ted has > already offered to start the required changes to e2fsck, which reminds me, I > have to send the promised docs. For now, just use normal fsck and it will > (in theory) turn the directory indexes back into normal file blocks, and have > no effect on inodes. This is only true without the COMPAT_DIR_INDEX flag. Since e2fsck _needs_ to know about every filesystem feature, it will (correctly) refuse to touch such a system for now. You could "tune2fs -O ^FEATURE_C4 /dev/hdX" to turn of the COMPAT_DIR_INDEX flag and let e2fsck go to town. That will break all of the directory indexes, I believe. 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[suggested PATCH]: /dev/guid support
Hello, This is a patch I sent to the Linux-IA64 mailing list some time ago. David Mosberger has suggested that I send it to linux-kernel to get broader feedback. Given support for GUID (UUID) entries in the partition table (as in the EFI partition table on IA-64 systems), and given devfs support in the kernel, the patch creates devfs links /dev/guid/[GUID] which allow to mount, fsck, partition, ... disks and partitions by their unique GUID. This wiull be quite helpful on large servers where the GUID, unlike disk and controller numbers, will stay constat even if disks or controllers are exchanged. If partitions are destroyed and created, the links in /dev/guid (dis)appear as well (thanks to devfs magic). The patch is against 2.4.5 + David Mosbergers IA64 patch (30/05/2001) from the "ports" directory. Feedback very welcome Martin -- Martin Wilck <[EMAIL PROTECTED]> FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 diff -ru linux-2.4.5/Documentation/Configure.help linux-2.4.5mw/Documentation/Configure.help --- linux-2.4.5/Documentation/Configure.helpMon Jun 25 14:45:01 2001 +++ linux-2.4.5mw/Documentation/Configure.help Mon Jun 25 15:48:11 2001 @@ -12036,6 +12036,12 @@ were partitioned using EFI GPT. Presently only useful on the IA-64 platform. +/dev/guid support (EXPERIMENTAL) +CONFIG_DEVFS_GUID + Say Y here if you would like to access disks and partitions by + their Globally Unique Identifiers (GUIDs) which will appear as + symbolic links in /dev/guid. + Ultrix partition support CONFIG_ULTRIX_PARTITION Say Y here if you would like to be able to read the hard disk diff -ru linux-2.4.5/fs/devfs/base.c linux-2.4.5mw/fs/devfs/base.c --- linux-2.4.5/fs/devfs/base.c Mon Jun 25 13:46:26 2001 +++ linux-2.4.5mw/fs/devfs/base.c Mon Jun 25 15:45:32 2001 @@ -1903,6 +1903,27 @@ return master->slave; } /* End Function devfs_get_unregister_slave */ +#ifdef CONFIG_DEVFS_GUID +/** + * devfs_unregister_slave - remove the slave that is unregistered when @master is +unregistered. + * Destroys the connection established by devfs_auto_unregister. + * + * @master: The master devfs entry. + */ + +void devfs_unregister_slave (devfs_handle_t master) +{ + devfs_handle_t slave; + + if (master == NULL) return; + + slave = master->slave; + if (slave) { + master->slave = NULL; + unregister (slave); + }; +} +#endif /* CONFIG_DEVFS_GUID */ /** * devfs_get_name - Get the name for a device entry in its parent directory. @@ -2103,6 +2124,9 @@ EXPORT_SYMBOL(devfs_get_next_sibling); EXPORT_SYMBOL(devfs_auto_unregister); EXPORT_SYMBOL(devfs_get_unregister_slave); +#ifdef CONFIG_DEVFS_GUID +EXPORT_SYMBOL(devfs_unregister_slave); +#endif EXPORT_SYMBOL(devfs_register_chrdev); EXPORT_SYMBOL(devfs_register_blkdev); EXPORT_SYMBOL(devfs_unregister_chrdev); diff -ru linux-2.4.5/fs/partitions/Config.in linux-2.4.5mw/fs/partitions/Config.in --- linux-2.4.5/fs/partitions/Config.in Mon Jun 25 14:45:01 2001 +++ linux-2.4.5mw/fs/partitions/Config.in Mon Jun 25 15:45:32 2001 @@ -25,6 +25,7 @@ bool 'Solaris (x86) partition table support' CONFIG_SOLARIS_X86_PARTITION bool 'Unixware slices support' CONFIG_UNIXWARE_DISKLABEL bool 'EFI GUID Partition support' CONFIG_EFI_PARTITION + dep_bool '/dev/guid support (EXPERIMENTAL)' CONFIG_DEVFS_GUID +$CONFIG_DEVFS_FS $CONFIG_EFI_PARTITION fi bool ' SGI partition support' CONFIG_SGI_PARTITION bool ' Ultrix partition table support' CONFIG_ULTRIX_PARTITION diff -ru linux-2.4.5/fs/partitions/check.c linux-2.4.5mw/fs/partitions/check.c --- linux-2.4.5/fs/partitions/check.c Mon Jun 25 14:45:01 2001 +++ linux-2.4.5mw/fs/partitions/check.c Mon Jun 25 15:45:32 2001 @@ -79,6 +79,20 @@ NULL }; +#ifdef CONFIG_DEVFS_GUID +static devfs_handle_t guid_top_handle; + +#define GUID_UNPARSED_LEN 36 +static void +uuid_unparse_1(efi_guid_t *guid, char *out) +{ + sprintf(out, "%08x-%04x-%04x-%02x%02x-%02x%02x%02x%02x%02x%02x", + guid->data1, guid->data2, guid->data3, + guid->data4[0], guid->data4[1], guid->data4[2], guid->data4[3], + guid->data4[4], guid->data4[5], guid->data4[6], guid->data4[7]); +} +#endif + /* * disk_name() is used by partition check code and the md driver. * It formats the devicename of the indicated disk into @@ -314,6 +328,101 @@ devfs_register_partitions (hd, i, hd->sizes ? 0 : 1); } +#ifdef CONFIG_DEVFS_GUID +/* + devfs_register_guid: create a /dev/guid entry for a disk or partition + if it has a GUID. + + The /dev/guid entry will be a symlink to the "real" devfs device. + It is marked as "slave" of the real device, + to be automatically unregistered by devfs if that device is unregistered. + + If the partition already had a /dev/guid entry, delete (unregister) it. + (If the disk was repartitioned, it's likely the old
Re: user limits for 'security'?
I suppose another question related to the first, is 'limit' checking part of the 'standard linux security' that embedded Linux users might find to be a waste of precious code-space? -l -- The above thoughts and| I know I don't know the opinions writings are my own. | of every part of my company. :-) L A Walsh, law at sgi.com | Sr Eng, Trust Technology 01-650-933-5338 | Core Linux, SGI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
[EMAIL PROTECTED] (Rob Landley) wrote on 24.06.01 in <[EMAIL PROTECTED]>: > Now if somebody here could just point me to a decent reference on A/UX - > Apple's mid-80's version of Unix (for the early macintosh, I believe...) http://www.google.com/search?q=%22%2ba/ux%22 Usually a good idea. Also, you probably want to look at RFC 2235. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
proc_file_read() question
Hi, the "hack" below in proc_file_read() fs/proc/generic.c (2.4.5) irritates me: If I do use "start" for a pointer into a memory area allocated in read_proc, will it be always guaranteed that (start > page)? If no, this will IMO lead to spuriously wrong output. If yes, I'd like to understand why. Regards & thanks, Martin /* This is a hack to allow mangling of file pos independent * of actual bytes read. Simply place the data at page, * return the bytes, and set `start' to the desired offset * as an unsigned int. - [EMAIL PROTECTED] */ n -= copy_to_user(buf, start < page ? page : start, n); if (n == 0) { if (retval == 0) retval = -EFAULT; break; } *ppos += start < page ? (long)start : n; /* Move down the file */ -- Martin Wilck <[EMAIL PROTECTED]> FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] wrong disk index in /proc/stat
Hi, I posted this patch already from my home mail account on June 20 (subject: disk_index weirdness), but no one seems to have noticed - therefore I try again. Those who _have_ noticed the other mail - sorry for bothering). The disk_index routine erroneously adds 2 to the index of disks on the first IDE controller which is wriong in 2.4, because disks are indexed by major number now. The patch fixes this and adds support for some more major numbers. (To fully benefit, DK_MAX_MAJOR in include/linux/kernel_stat.h must be increased). The patch is against plain 2.4.5. Regards, Martin -- Martin Wilck <[EMAIL PROTECTED]> FSC EP PS DS1, Paderborn Tel. +49 5251 8 15113 diff -ru linux-2.4.5/include/linux/genhd.h linux-2.4.5mw/include/linux/genhd.h --- linux-2.4.5/include/linux/genhd.h Tue Mar 27 01:48:11 2001 +++ linux-2.4.5mw/include/linux/genhd.h Mon Jun 25 14:23:57 2001 @@ -248,21 +248,30 @@ unsigned int index; switch (major) { - case DAC960_MAJOR+0: - index = (minor & 0x00f8) >> 3; - break; case SCSI_DISK0_MAJOR: index = (minor & 0x00f0) >> 4; break; case IDE0_MAJOR:/* same as HD_MAJOR */ case XT_DISK_MAJOR: + case IDE1_MAJOR: + case IDE2_MAJOR: + case IDE3_MAJOR: + case IDE4_MAJOR: + case IDE5_MAJOR: index = (minor & 0x0040) >> 6; break; - case IDE1_MAJOR: - index = ((minor & 0x0040) >> 6) + 2; + case SCSI_CDROM_MAJOR: + index = minor & 0x000f; break; default: - return 0; + if (major >= SCSI_DISK1_MAJOR && major <= SCSI_DISK7_MAJOR) + index = (minor & 0x00f0) >> 4; + else if (major >= DAC960_MAJOR && major <= DAC960_MAJOR + 7) + index = (minor & 0x00f8) >> 3; + else if (major >= IDE6_MAJOR && major <= IDE9_MAJOR) + index = (minor & 0x0040) >> 6; + else + return 0; } return index; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
Hi again i have a stack now an #0 schedule () at sched.c:536 #1 0x1002f932 in __wait_on_buffer (bh=0x50eb16e4) at buffer.c:157 #2 0x10036f46 in block_read (filp=0x5009787c, buf=0x80c08f0 "¤\201", count=8192, ppos=0x5009789c) at /home/mistral/dev/kernel/linux-2.4.5-um9/include/linux/locks.h:20 #3 0x1002eb4b in sys_read (fd=3, buf=0x80c00f0 "¤\201", count=8192) at read_write.c:133 #4 0x100fb807 in execute_syscall (regs={regs = {3, 135004400, 8192, 1283476480, 0, 3212835652, 4294967258, 43, 43, 0, 0, 3, 1074582884, 35, 582, 3212835588, 43}}) at syscall_kern.c:332 #5 0x100fb926 in syscall_handler (unused=0x0) at syscall_user.c:80 this should still be on #umldebug on irc.openproject.net for the next few ours if anybodys intresting at taking a look though gdb via a bot. James -- - Web: http://www.stev.org Mobile: +44 07779080838 E-Mail: [EMAIL PROTECTED] 8:30pm up 2 days, 42 min, 4 users, load average: 1.00, 0.94, 0.64 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
user limits for 'security'?
I've seen some people saying that user-limits are an essential part of a secure system to prevent local DoS attacks. Given that, should a system call like 'fork' return -EPERM if the user has reached their limit? My local manpage (SuSE 7.2 system) says this under fork: ERRORS EAGAIN fork cannot allocate sufficient memory to copy the parent's page tables and allocate a task structure for the child. - Should the man page be updated to reflect that EAGAIN is returned when the user has reached their limit? From a user-monitoring point of view, it might be security relevant to know if a EAGAIN is being returned because the system really is low on resources or if it is a user hitting their limit. -- The above thoughts and| I know I don't know the opinions writings are my own. | of every part of my company. :-) L A Walsh, law at sgi.com | Sr Eng, Trust Technology 01-650-933-5338 | Core Linux, SGI - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MemShared == 0 ?
On Mon, Jun 25, 2001 at 11:21:55AM +0100, Rodrigo Ventura wrote: > /proc> cat version meminfo > Linux version 2.4.6-pre3 (yoda@damasio) (gcc version 2.95.2 19991024 (release)) #3 >Mon Jun 18 19:00:11 WEST 2001 > total:used:free: shared: buffers: cached: > Mem: 261779456 256925696 48537600 134025216 82280448 > Swap: 271425536 10993664 260431872 > MemTotal: 255644 kB \ > MemFree: 4740 kB \ > MemShared: 0 kB << What's the meaning of this? * Check the lkml FAQ: http://www.tux.org/lkml/#s14-3 Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
On Monday 25 June 2001 11:13, you wrote: > 1937 claude shannon A Symbolic Analysis of Relay and Switching Circuits," > > 1948 claude shannon A mathematical theory of information. > > without those you're kind in trouble on the computing front... Yeah, I know I've bumped into that name (and probably taken notes) somewhere. Hmmm... Might be from "Where wizards stay up late", or might have been an article linked from slashdot... (I don't THINK it was mentioned in "Hackers"... Rodents, where was the reference... Crystal fire? That's mostly hardware. Accidental Empries? Doesn't sound right... Can't have been "Fire in the valley" because I haven't read that yet, it's still sitting on the bookshelf. Not soul of a new machine, that's post-digital Equipment Corporation...) I THINK that's in the set of notes that's on the box that's not hooked up right now... (Shortage of monitors at home.) This was the dude who decided to apply a binary and boolean approach to electronic computation, right? I KNOW I've read some stuff about him... late last year? Now I remember. Slashdot linked to his obituary: http://www.bell-labs.com/news/2001/february/26/1.html Rob The list for this discussion is: http://lists.sourceforge.net/lists/listinfo/penguicon-comphist - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
Hi i have been looking at it a lot over the past few days i seem to be the person who can trigger it easyest. over the past couple of days i have been running with the #define WAITQUEUE_DEBUG 1 no problems seem to have appeared there though and the bug still triggers. On Mon, 25 Jun 2001, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > I am running in to a problem, seemingly a deadlock situation, where > > almost all the processes end up in the TASK_UNINTERRUPTIBLE state. > > All the process eventually stop responding, including login shell, no > > screen updates, keyboard etc. Can ping and sysrq key works. I > > traced the tasks through sysrq-t key. The processors are in the idle > > state. Tasks all seem to get stuck in the __wait_on_page or > > __lock_page. i also seem to get ut ub __wait_on_buffer and ___wait_on_page James -- - Web: http://www.stev.org Mobile: +44 07779080838 E-Mail: [EMAIL PROTECTED] 8:00pm up 2 days, 12 min, 4 users, load average: 1.41, 0.38, 0.40 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
[EMAIL PROTECTED] (Rob Landley) wrote on 23.06.01 in <[EMAIL PROTECTED]>: > on April 2, 1987. (models 50, 60, and 80.) The SAA/SNA push also extended > through the System/370 and AS400 stuff too. (I think 370's the mainframe > and AS400 is the minicomputer, but I'd have to look it up. One of them > (AS400?) had a database built into the OS. Interestingly, this is where SQL > originated (my notes say SQL came from the System/370 but I have to > double-check that, I thought the AS400 was the one with the built in > database?). The AS/400 is still going strong. It's a virtual machine based on a relational database (among other things), mostly programmed in COBOL (I think the C compiler has sizeof(void*) == 16 or something like that, so you can put a database position in that pointer), it doesn't know the difference between disk and memory (memory is *really* only a cache), and these days it's usually running on PowerPC hardware. ISTR there's a gcc port for the AS/400. Oh, and it does have normal BSD Sockets. These days, it's often sold as a web server. Main customer base seems to be medium large businesses and banks. > Lotus-Intel-Microsoft Expanded Memory Specification), and "DOSShell" which > conformed to the SAA graphical user interface guidelines. Nope, the text user interface guidelines, a related but not the same beast. That's where F1 == Help is from, by the way. In fact, the user interface part of SAA was (is?) called CUA. And many IBM text mode interfaces more or less follow it, including OS/400 (the os of the AS/400). Once upon a time, I had the specs for CUA. > The PS/2 model 70/80 (desktop/tower versions of same thing) were IBM's first > 386 based PC boxes, which came with either DOS 3.3, DOS 4.0, OS/2 (1.0), or > AIX. The first 386 PCs where not from IBM, by the way. Was it Compaq? > AIX was NOT fully SAA/SNA compliant, AFAICT, nothing ever was fully SAA compliant, though some systems were more compliant than others. > Hmmm... Notes on the history of shareware (pc-write/bob wallace/quiicksoft, > pc-file/pc-calc/jim button/buttonware, pc-talk/andrew flugelman, apparently > the chronological order is andrew-jim-bob, and bob came up with the name > "shareware" because "freeware" was a trademark of Headlands Press, Inc...) That may be, but I believe the *concept* was invented in 1980 by Bill Basham, with the Apple ][ DOS replacement Diversi-DOS (which was the most popular of many versions to increase disk speed by about a factor of 5). I still remember discussions how copying this stuff was actually the right thing to do. Seems he's still in business as "Diversified Software Research", http://www.divtune.com/. > running AIX. The engineers (in Austin) whent on for the second generation > Risc System 6000 (the RS/6000) with AIX version 3, launched February 15 > 1990. The acronym "POWER" stands for Performance Optimized WIth Enhanced > Risc. The PowerPC was split off from the POWER architecture, and then the POWER stuff was turned into the high end above PowerPC (with system prices about a factor of ten higher as the lower bound). IBM developed a version of OS/2 2.0 for the PowerPC, but *never* marketed it - you could buy it if you knew the right number, but they never spent a single cent on advertizing - by the time it was done, IBM had given up on OS/2. Most OS/2 fans agreed that it was killed by IBM with extremely bad marketing. These days, of course Apple builds the most PowerPC machines; Motorola and IBM produce the chips. > Ummm... GEM was the Geos stuff? No. GEM, I believe, originally came from CP/M. Most popular as the windowing system of the Atari ST; given that someone did a quick-hack MS- DOS clone to support it on the 68K, it seems fairly obvious that by that time, it had already been ported to MS-DOS. (GEM-DOS is the only os I know of that was actually worse than MS-DOS.) Friends of mine (Gereon Steffens and Stefan Eissing) wrote a command-line shell and desktop replacement for the Atari that was fairly successful shareware for a while ... now how was it called? The CLI was Mupfel (German for shell is Muschel, and there was a kid's TV character who pronounced Muschel as Mupfel), and I think the desktop was Gemini. Another (Julian Reschke) wrote *the* German Atari ST book. This was a fairly prominent Atari ST area for a while, but somehow I never had one. > Using 3d accelerator cards to play MPEG video streams is only now becoming > feasable to do under X. And it SHOULD be possible to do that through a > 100baseT network, let alone gigabit, but the layering's all wrong...) One might say it's time for X12, except the installed base of X11 has become too large. MfG Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/
Re: Linux 2.4.6-pre3 breaks ReiserFS mount on boot
Not /dev/hda42, thats odd. From 2.4.5 -> 2.4.6 ReiserFS would refuse to mount the drive on startup. I noticed in pre5 there was a reiserfs fix to something but im not sure if its related or not. My domain is also back so I'm going to resubscribe. Shawn. On Tue, 19 Jun 2001, Neil Brown wrote: > On Tuesday June 19, [EMAIL PROTECTED] wrote: > > On Mon, Jun 18, 2001 at 11:57:16PM -0400, Shawn Starr wrote: > > > > > > read_super_block: can't find a reiserfs filesystem on dev 03:42 > > > read_old_super_block: try to find super block in old location > > > read_old_super_block: can't find a reiserfs filesystem on dev 03:42 > > > Kernel Panic: VFS: Unable to mount root fs on 03:42 > > > > > > my super block broke somewhere? > > > > Out of curiousity, what device are you trying to boot from? 03:42, at least > > according to linux/Documentation/devices.txt, corresponds to /dev/hda42. > > or, noting that kdevname used hexadecimal, > /dev/hdb2 > > NeilBrown > > > > > Is that really the disk you're trying to mount? I'm not familiar with how > > some IDE RAID controllers present disks, but it was the first thing I > > noticed. > > > > -Jeff > > > > -- > > Jeff Mahoney > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > - > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > the body of a message to [EMAIL PROTECTED] > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
problems with my plexwriter 8/4/32A drive..
I am using AMD 1.2Gig w/ 512Meg Ram, MSI 6330-K7ProA motherboard. hda: QUANTUM FIREBALLP LM10.2, ATA DISK drive hdb: IBM-DPTA-372050, ATA DISK drive hdc: ATAPI 52X CDROM, ATAPI CD/DVD-ROM drive hdd: PLEXTOR CD-R PX-W8432T, ATAPI CD/DVD-ROM drive base install is Mandrake 8.0 from CD it did not work and then tried latest cooker kernel 2.4.5-8 same thing. I have also tried redhat 7.1 with all recommended updates 2.4.3-12 kernel same thing. using ide-scsi module. SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices Vendor: PLEXTOR Model: CD-R PX-W8432T Rev: 1.09 Type: CD-ROM ANSI SCSI revision: 02 when trying to mount a CD in the plextor the system accesses the drive for a few seconds then hangs the process hangs and can not be killed. If I use X-CD-Roast it tries to access the drive and after a few seconds the CPU goes to 100% usage and hangs the machine, have to hard reset it can not sys-req it either. The other CD-Rom drive works great. This setup works great under a dual boot of Windows 2000, and I can access the drive and burn CD's all day long. cdrecord --scanbus see's the drive the until the first time I try to access it the drive, then cdrecord --scanbus hangs. Cdrecord 1.9 (i686-pc-linux-gnu) Copyright (C) 1995-2000 Jörg Schilling Linux sg driver version: 3.1.17 Using libscg version 'schily-0.1' scsibus0: 0,0,0 0) 'PLEXTOR ' 'CD-R PX-W8432T' '1.09' Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * I will attach my dmesg... Please help. Thanks Jorg Linux version 2.4.3-12 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85)) #1 Fri Jun 8 13:35:30 EDT 2001 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 1fff3000 (ACPI NVS) BIOS-e820: 1fff3000 - 2000 (ACPI data) BIOS-e820: - 0001 (reserved) On node 0 totalpages: 131056 zone(0): 4096 pages. zone(1): 126960 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=347 BOOT_FILE=/boot/vmlinuz-2.4.3-12 hdd=ide-scsi ide_setup: hdd=ide-scsi Initializing CPU#0 Detected 1331.610 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 2654.20 BogoMIPS Memory: 509088k/524224k available (1246k kernel code, 10656k reserved, 93k data, 228k init, 0k highmem) Dentry-cache hash table entries: 65536 (order: 7, 524288 bytes) Buffer-cache hash table entries: 32768 (order: 5, 131072 bytes) Page-cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) VFS: Diskquotas version dquot_6.5.0 initialized CPU: Before vendor init, caps: 0183f9ff c1c7f9ff , vendor = 2 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU: After vendor init, caps: 0183f9ff c1c7f9ff CPU: After generic, caps: 0183f9ff c1c7f9ff CPU: Common caps: 0183f9ff c1c7f9ff CPU: AMD Athlon(tm) Processor stepping 02 Enabling fast FPU save and restore... done. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xfb250, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware Unknown bridge resource 0: assuming transparent PCI: Using IRQ router VIA [1106/0686] at 00:07.0 PCI: Found IRQ 10 for device 00:07.2 PCI: The same IRQ used for device 00:07.3 Applying VIA PCI latency patch (found VT82C686B). isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket apm: BIOS version 1.2 Flags 0x07 (Driver version 1.14) Starting kswapd v1.8 pty: 512 Unix98 ptys configured block: queued sectors max/low 338074kB/207002kB, 1024 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx VP_IDE: IDE controller on PCI bus 00 dev 39 VP_IDE: chipset revision 6 VP_IDE: not 100% native mode: will probe irqs later VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci00:07.1 ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
Re: Microsoft and Xenix.
Hi, On Mon, Jun 25, 2001 at 06:27:24PM +0100, [EMAIL PROTECTED] wrote: > I first used Unix on a PDP11/44 whilst studying for my Computer Engineering > degree at Heriot-Watt University in Edinburgh. I think they and Queen Margaret > College, London were the first folk running Unix version 6 outside Bell Labs. Hey! Don't forget UKC ;-) Cut my teeth on pdp11 v6 and VAXen BSD 4.1 once I got away from the dreaded EMAS. Edinbugh Multi-Access System was the pitts. > I then used SCO Xenix 286 on early Compaq 286 PC's. Companies like Chase, > Specialix and Stallion grew up as suppliers of intelligent RS-232 boards. As > a result of all these Xenix machines, Wyse sold a hell of a lot of WY50 > terminals. Great days. The business was so incestuous. We seemed to swap engineers on a regular basis. Hacking drivers without kernel source and documentation that always seemed at least a release behind. Still keep a WY60 manual on my book shelf and always regret losing the VT100 one. > Who remembers terminals from Lear Siegler and Beehive. All this was before > networking came about. Then the Chase Iolan to connect these same Wyse > terminals to the SCO box but through one bit of co-ax instead of multi-core > cables. Also you could get 100m away from your SCO box with co-ax. And the trouble we had explaining to customers that they had to buy a separate SCO TCP/IP networking package just to hook up the IOLAN. -- Bob Dunlop [EMAIL PROTECTED] www.xyzzy.clara.co.uk - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops in iput
Hi, oops in iput - Kernel 2.2.19/i386 + ide-udma patches + ext3 patches (0.0.7a) Intel BX chipset, SCSI Disks Symbios chipset - The crashing process is the master process of "postfix" an MTA. Just before the crash all processes on that machine started to segfault in nameserver resolution (remote dns server) and after 2-3 minutes this oops happened. ksymoops 2.3.4 on i686 2.2.19. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.2.19/ (default) -m /boot/System.map-2.2.19 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Unable to handle kernel paging request at virtual address 4ed90398 current->tss.cr3 = 00101000, %cr3 = 00101000 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 4ed90330 ebx: ecx: edx: c01eef0c esi: 4ed90330 edi: ce27ed00 ebp: 0002 esp: cf04ddac ds: 0018 es: 0018 ss: 0018 Process master (pid: 297, process nr: 31, stackpage=cf04d000) Stack: cf1859a0 0001 cef7db18 cef7db18 cf1859a0 c015882f 4ed90330 ce27ec80 0002 ced90330 ced90330 ce27ed00 0002 ceadc0c0 cfce5860 c0158be3 ced903e0 ceeda140 0002 ceeda140 ced90330 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 46 68 85 c0 74 09 8b 40 18 85 c0 74 02 89 c3 85 db 74 10 >>EIP; c0133ca7<= Trace; c015882f Trace; c0158be3 Trace; c011b26c Trace; c01262bd <__fput+25/54> Trace; c011d2b5 Trace; c012745c Trace; c0127453 Trace; c01139bb Trace; c012634b Trace; c011073e Trace; c0113958 Trace; c01184f4 Trace; c011847d Trace; c0109fbb Trace; c0b1 Trace; c0109583 Trace; c010a100 Code; c0133ca7 <_EIP>: Code; c0133ca7<= 0: 8b 46 68 mov0x68(%esi),%eax <= Code; c0133caa 3: 85 c0 test %eax,%eax Code; c0133cac 5: 74 09 je 10 <_EIP+0x10> c0133cb7 Code; c0133cae 7: 8b 40 18 mov0x18(%eax),%eax Code; c0133cb1 a: 85 c0 test %eax,%eax Code; c0133cb3 c: 74 02 je 10 <_EIP+0x10> c0133cb7 Code; c0133cb5 e: 89 c3 mov%eax,%ebx Code; c0133cb7 10: 85 db test %ebx,%ebx Code; c0133cb9 12: 74 10 je 24 <_EIP+0x24> c0133ccb 1 warning issued. Results may not be reliable. -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 Why is it called "common sense" when nobody seems to have any? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
On Thu, Jun 21, 2001 at 02:21:18PM -0400, Rob Landley wrote: > Name one thing Microsoft actually invented. Other than Microsoft Bob. I remember there being a web page where all of Microsoft's "innovations" were listed and where they bought or stole it from. The only things that were really Microsoft's invention were, at that time, found to be a) the .ini config file format (which has spread outside of the MS world) and b) the annoying paper clip. Does anyone have the URL handy? Try finding that in a search engine... -- Andreas E. Bombe <[EMAIL PROTECTED]>DSA key 0x04880A44 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in 3c905 driver.
William Park wrote: > > On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote: > > Just a note... > > > > This card get's detected twofold by the plain 2.4.5 kernel. > > It get's listed twice under both lspci and during the kernel boot > > sequence on a HP LHr3 system. > > I get only one message, I have 3c905CX and 2.4.5 kernel. Maybe you have > 2 cards inside? ;-) Could you hand me your .config file over. Maybe there is something sensitive in the choices for PCI acess, Power management or not - or whatever else it may be. I would like to confirm the true source of this error. (Currently I'm guessing at a buggy compiler provided by SuSE or buggs in the PCI setup code or some wired kind of BIOS configuration problem). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux and system area networks
I'd like to find out if anyone has thought about how Linux will handle some of the new network technologies people are starting to push. Specifically I'm talking about "System Area Networks," that is, things like Infiniband, as well as TCP/IP offload. In the past people have advocated VIA as a way to use network hardware that provides reliability and remote DMA (RDMA). However, VI never really caught on because it requires applications to be completely rewritten. In addition, the corporate backers of VI seem to have mostly given up on it. Late last year, Network Appliance proposed something they called "DASockets," which would mostly preserve socket semantics. However that seems to have been put on hold. Microsoft recently introduced something called "Winsock Direct" in W2K Datacenter. For more info you can look at: http://www.microsoft.com/windows2000/en/datacenter/help/default.asp?url=/WINDOWS2000/en/datacenter/help/WSD_and_SAN.htm The rough idea is that WSD is a new user space library that looks at sockets calls and decides if they have to go through the usual kernel network stack, or if they can be handed off to a "SAN service provider" which bypasses the network stack and uses hardware reliable transport and possibly RDMA. This means that all applications that use Winsock benefit from the advanced network hardware. Also, it means that Windows is much easier for hardware vendors to support than other OSes. For example, Alacritech's TCP/IP offload NIC only works under Windows. Microsoft is also including Infiniband support in Windows XP and Windows 2002. (Intel will be pushing Infiniband onto motherboards pretty soon, which will bring reliable transport, RDMA network hardware into the mainstream) So I guess my question is whether anyone has started thinking about the architectural changes needed to make System Area Networking and TCP/IP offload easier under Linux. Thanks, Roland -- Roland Dreier<[EMAIL PROTECTED]> GPG Key fingerprint = A89F B5E9 C185 F34D BD50 4009 37E2 25CC E0EE FAC0 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VM tuning through fault trace gathering [with actual code]
On 25 Jun 2001, John Fremlin wrote: > Last year I had the idea of tracing the memory accesses of the system > to improve the VM - the traces could be used to test algorithms in > userspace. The difficulty is of course making all memory accesses > fault without destroying system performance. Sounds like a cool idea. One thing you should keep in mind though is to gather traces of the WHOLE SYSTEM and not of individual applications. There has to be a way to balance the eviction of pages from applications against those of other applications. 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://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Where is check for superuser in TCP port bind.
> > Obviously (to me) this check is in tcp_v4_get_port(). > But, I can't find it, or perhaps it's better hidden than I thought. > Or maybe I'm just very confused. > Any help would be most welcome. The above poster was of course deeply stupid, and could have done with more sleep :) It's in net/ipv4/af_inet.c I was looking for some way of letting users own devices, so they can do some subset of the operations reserved for root on their device. Further reading led to "route by owner" in netfilter, but it's not quite it. This would let me do something like: ifconfig eth0:www 1.2.3.4 route add default 1.2.3.4 -user www But would still not let www bind low ports on eth0:www. There seem to be a few ways to do this. Teach capable() about owned routes. Make interfaces/aliases directly ownable, add CAP_NET_BIND_ANY so you can only bind to an interface you own, or if you have CAP_NET_BIND_ANY. You need CAP_NET_BIND_ANY to chown an interface. The second way seems cleaner to me. Any comments? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What are the VM motivations??
On Mon, 25 Jun 2001, Colonel wrote: > As a physicist, I learned long ago that if you cannot use the back of > an envelope and explain your theory to a secretary, you do not > understand it. It has only been revealed recently where some VM > design information may be hidden, and it's apparently out of date. > Maintenance requires good documentation, especially in critical areas. > I hope that your suggestion succeeds, and that a document is passed > around, but I'll bet a large amount that it doesn't happen. Your contributions are welcome. I'm looking forward to your updated documentation and patches. 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://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What are the VM motivations??
On Sun, 24 Jun 2001, Colonel wrote: > >May I suggested an algorithm? > > > > - Write down what you think the optimization constraints are. > >(be specific, for example, enumerate all the flavors of page types - > >process code, process data, page cache file data, page cache swap > >cache, anonymous, shmem, etc.) > > > > - Write down what you think the current algorithms are. > >(again, be specific, use file names, function names, pseudocode and > >snippets of existing code.) > > > > - Send it to Rik. He'll tell you if it's right. > > POST IT. Give the rest of us some clues and the opportunity to check > evaluator's replies. Why don't YOU post it? All I've seen from you are complaints and insults, nothing constructive yet. 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://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Some experience of linux on a Laptop
>From Android on Sunday, 24 June, 2001: >>I have come to the conclusion that linux is NOT suitable for the general >>desktop market. >I have to disagree on this. It runs fine on most PC's, as they use standard >devices. Just say NO to anything proprietary. This includes Toshiba. Makers of such >odd machines should supply their own native drivers if they want to be supported. I would have to concur, if it weren't for almost all manufacturers doing this. Grr. >>5: Better support for toshiba computers... well try =) >Talk to Toshiba. See if they are willing to part with "secret" information >so that you can create specific drivers for Linux. After that, I bet your next comp. >won't be from them. :-) I've been talking sometimes on the Toshiba list, trying to get Toshiba to support Linux officially (they do *unofficially*, as shown by the inclusion of Linux in a lot of their website). However, it doesn't look likely. I'd like everyone's help pressing Toshiba to open up some more of their specs. That'd be the ideal solution. I guess I'd go for binary-only drivers, if they'd maintain them well. It's sub-optimal, but it's a workaround for now. :) If you have Toshiba hardware, *please* tell them to support Linux every chance you get. Maybe after enough feedback from the community, they'll wise up. Oh, FYI, I am running the unstable distribution of Debian with the 2.4.5 kernel. Everything on my Satellite 1605CDS laptop works, with the notable exception of the scheiss-Winmodem. I've been talking with Conextant (the winmodem chipset manufacturers), so I'll see where that gets me. Be sure that if I get sufficient info (and time!!), I'll post what I know and *maybe* even deveop a pseudo-serial port driver. That'd require a *lot* of time, though, and time is in very short supply right now. :) Anyway, the basic message I wanted to convey was that you need to pressure your hardware manufacturer of choice to open up their specs so that *everyone* can use their hardware with whatever software they choose. It helps find bugs ("your spec says X, but the hardware *really* does Y"), and hey, they can hire only a minimal staff to do Linux support (if they offload the driver development and maintenance to the kernel developers. :) If something doesn't work with Linux, given experience and the sheer number of developers, chances are *very* good that the manufacturer is hoarding the specs. Unfortunately, it's a common practice that requires a good kick in the hiney. :) -Joseph -- [EMAIL PROTECTED] "IBM were providing source code in the 1960's under similar terms. VMS source code was available under limited licenses to customers from the beginning. Microsoft are catching up with 1960." --Alan Cox, http://www2.usermagnet.com/cox/index.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
On Mon, 25 Jun 2001, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > Can you give more details? Was there an aic7xxx scsi driver on the > > box? run_task_queue(&tq_disk) should eventually unlock those pages but > > they remain locked. I am trying to narrow it down to fs/buffer code > > or the SCSI driver aic7xxx in my case. > > Rik would be the one to tell you whether there was an aic7xxx driver > on the physical box. There obviously isn't one on UML, so if we're > looking at the same bug, it's in the generic code. The box has as AIC-7880U controller. OTOH, my dual P5 also has an AIC7xxx controller and I've never seen the problem there... On our quad Xeon this problem really seems to be phase-of-moon related; it hasn't shown up in the last 5 days or so under heavy stress testing, but when the kernel is compiled just a little bit different it doesn't happen. ;) 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://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: ACPI + Promise IDE = disk corruption :-(((
Their processor power state code looks dormant at the moment, so they haven't hit this particular issue. They have in the past run into a number of problems, and submitted fixes. The Linux version is getting much wider testing right now. -- Andy PS Just FreeBSD, no Net or OpenBSD just yet. > From: Chris Wedgwood [mailto:[EMAIL PROTECTED]] >> It's just *one* issue that has generated all the disk corruption >> reports. > > The same code is used for FreeBSD and friends too right? Are they > seeing anywhere near the same number of types of poroblems Linux is? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] rio500 devfs support
On Tue, Jun 19, 2001 at 05:52:24PM -0500, Gregory T. Norris wrote: > The attached diff adds devfs support to the rio500 driver, so that > /dev/usb/rio500 gets created automagically. It was generated against > 2.4.5, but probably applies fine against any recent kernel. Comments > are welcome (but be gentle, this is my first attempt at a kernel > patch :-). Here's a small change that makes the node a child of the usb devfs entry. It also enables the node to only be present when the device is actually present. The patch is against 2.4.6-pre5. thanks, greg k-h diff -Nru a/drivers/usb/rio500.c b/drivers/usb/rio500.c --- a/drivers/usb/rio500.c Mon Jun 25 10:31:03 2001 +++ b/drivers/usb/rio500.c Mon Jun 25 10:31:03 2001 @@ -38,13 +38,14 @@ #include #include #include +#include #include "rio500_usb.h" /* * Version Information */ -#define DRIVER_VERSION "v1.0.0" +#define DRIVER_VERSION "v1.1" #define DRIVER_AUTHOR "Cesar Miquel <[EMAIL PROTECTED]>" #define DRIVER_DESC "USB Rio 500 driver" @@ -60,6 +61,7 @@ struct rio_usb_data { struct usb_device *rio_dev; /* init: probe_rio */ +devfs_handle_t devfs; /* devfs device */ unsigned int ifnum; /* Interface number of the USB device */ int isopen; /* nz if open */ int present;/* Device is present on the bus */ @@ -69,6 +71,8 @@ struct semaphore lock; /* general race avoidance */ }; +extern devfs_handle_t usb_devfs_handle;/* /dev/usb dir. */ + static struct rio_usb_data rio_instance; static int open_rio(struct inode *inode, struct file *file) @@ -416,6 +420,15 @@ return read_count; } +static struct +file_operations usb_rio_fops = { + read: read_rio, + write: write_rio, + ioctl: ioctl_rio, + open: open_rio, + release:close_rio, +}; + static void *probe_rio(struct usb_device *dev, unsigned int ifnum, const struct usb_device_id *id) { @@ -439,6 +452,14 @@ } dbg("probe_rio: ibuf address:%p", rio->ibuf); + rio->devfs = devfs_register(usb_devfs_handle, "rio500", + DEVFS_FL_DEFAULT, USB_MAJOR, + RIO_MINOR, + S_IFCHR | S_IRUSR | S_IWUSR | S_IRGRP | + S_IWGRP, &usb_rio_fops, NULL); + if (rio->devfs == NULL) + dbg("probe_rio: device node registration failed"); + init_MUTEX(&(rio->lock)); return rio; @@ -448,6 +469,8 @@ { struct rio_usb_data *rio = (struct rio_usb_data *) ptr; + devfs_unregister(rio->devfs); + if (rio->isopen) { rio->isopen = 0; /* better let it finish - the release will do whats needed */ @@ -461,15 +484,6 @@ rio->present = 0; } - -static struct -file_operations usb_rio_fops = { - read: read_rio, - write: write_rio, - ioctl: ioctl_rio, - open: open_rio, - release:close_rio, -}; static struct usb_device_id rio_table [] = { { USB_DEVICE(0x0841, 1) }, /* Rio 500 */
Re: Microsoft and Xenix.
Beehive -- there's a name I haven't heard in a long time! The ones I remember had dual floppy drives and ran CP/M. I last saw one in about 1985. Wayne [EMAIL PROTECTED] on 06/25/2001 12:11:01 PM To: William T Wilson <[EMAIL PROTECTED]> cc: Rob Landley <[EMAIL PROTECTED]>, "Eric W. Biederman" <[EMAIL PROTECTED]>, Alan Chandler <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (bcc: Wayne Brown/Corporate/Altec) Subject: Re: Microsoft and Xenix. Hi, I first used Unix on a PDP11/44 whilst studying for my Computer Engineering degree at Heriot-Watt University in Edinburgh. I think they and Queen Margaret College, London were the first folk running Unix version 6 outside Bell Labs. If anyone knows where Patrick O'Callaghan is now (ask him). Another Unix like OS was Cromemco Cromix running on bank switched Z80 S-100 kit.(later 68000). I then used SCO Xenix 286 on early Compaq 286 PC's. Companies like Chase, Specialix and Stallion grew up as suppliers of intelligent RS-232 boards. As a result of all these Xenix machines, Wyse sold a hell of a lot of WY50 terminals. Who remembers terminals from Lear Siegler and Beehive. All this was before networking came about. Then the Chase Iolan to connect these same Wyse terminals to the SCO box but through one bit of co-ax instead of multi-core cables. Also you could get 100m away from your SCO box with co-ax. -- Andrew Smith in Edinburgh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
Hi, If you're really keen on old mags and manuals I'll go up to attic and look around. I know there are old SCO Xenix & TCP/IP, as well as Byte and Dr Dobbs On Sun, 24 Jun 2001 [EMAIL PROTECTED] wrote: -- Andrew Smith in Edinburgh > Sorry, but I'm hanging on to my old computer manuals. The AIX manuals in > particular have sentimemtal value for me. > > OTOH, I have quite a few old computer magazines (from the 80's) like Byte, > Infoworld, etc. I've been intending to get rid of them for some time now, but > hated just to throw them away. They're in storage in a neighboring state right > now, but my wife probably will be driving there in the next couple of weeks to > pick up a few things. If you're interested, she could bring back the magazines > and I can tell you exactly what I have. You're welcome to them if you want > them. > > Wayne > > > > > Rob Landley <[EMAIL PROTECTED]> on 06/24/2001 09:32:43 AM > > Please respond to [EMAIL PROTECTED] > > To: Wayne Brown/Corporate/Altec@Altec, John Adams <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED] > > Subject: Re: Microsoft and Xenix. > > > > On Saturday 23 June 2001 22:41, [EMAIL PROTECTED] wrote: > > Ah, yes, the RT/PC. That brings back some fond memories. My first > > exposure to Unix was with AIX on the RT. I still have some of those > > weird-sized RT AIX manuals around somewhere... > > > > Wayne > > Ooh! Old manuals! > > Would you be willing to part with them? > > I am collecting old manuals, and old computing magazines. I even pay for > postage, with a bit of warning that they're coming... > > Rob > > > > > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Microsoft and Xenix.
Hi, I first used Unix on a PDP11/44 whilst studying for my Computer Engineering degree at Heriot-Watt University in Edinburgh. I think they and Queen Margaret College, London were the first folk running Unix version 6 outside Bell Labs. If anyone knows where Patrick O'Callaghan is now (ask him). Another Unix like OS was Cromemco Cromix running on bank switched Z80 S-100 kit.(later 68000). I then used SCO Xenix 286 on early Compaq 286 PC's. Companies like Chase, Specialix and Stallion grew up as suppliers of intelligent RS-232 boards. As a result of all these Xenix machines, Wyse sold a hell of a lot of WY50 terminals. Who remembers terminals from Lear Siegler and Beehive. All this was before networking came about. Then the Chase Iolan to connect these same Wyse terminals to the SCO box but through one bit of co-ax instead of multi-core cables. Also you could get 100m away from your SCO box with co-ax. -- Andrew Smith in Edinburgh On Sun, 24 Jun 2001, William T Wilson wrote: > On Sun, 24 Jun 2001, Rob Landley wrote: > > > I know the geos had nothing to do with digital, it started as a > > windowing GUI for the commodore 64, if you can believe that... > > I've actually got a copy, but it's for the Apple // :} > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bug in 3c905 driver.
On Mon, Jun 25, 2001 at 08:51:28PM +0200, Martin Dalecki wrote: > Just a note... > > This card get's detected twofold by the plain 2.4.5 kernel. > It get's listed twice under both lspci and during the kernel boot > sequence on a HP LHr3 system. I get only one message, I have 3c905CX and 2.4.5 kernel. Maybe you have 2 cards inside? ;-) -- William Park, Open Geometry Consulting, <[EMAIL PROTECTED]> 8 CPUs cluster, (Slackware) Linux, Python, LaTeX, Vim, Mutt, Sc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Making a module 2.4 compatible
On Mon, 25 Jun 2001, Timur Tabi wrote: > ** Reply to message from James Lamanna <[EMAIL PROTECTED]> on Sat, 23 > Jun 2001 22:10:58 -0700 > > > > It would be nice to have it working under 2.4, so is there someplace > > that outlines some of the major things that would have changed so I can > > update the module accordingly? > > Unfortunately, no. But if it turns out I'm wrong, please let me know what you > find. > As a start: wait_queue_head_t Now defined. You can do '#if !defined(...)` and make code changes backwards compatible. Macro, THIS_MODULE is now the first member of struct file_operations. Include __init data type for one-time initialization code or data. This is new, hense not backwards compatible. Explicit initialization of spin-locks, SPIN_LOCK_UNLOCKED and/or spin_lock_init(spinlock_t *); If you fix this, it's backwards compatible. ioremap() and friends is now required even for low memory stuff. You can no longer access this with a simple pointer, you must use readl()/writel(), etc., for proper defererence. If you fix this, it's backwards compatible. These changes should get your module to compile (or nearly so). Cheers, Dick Johnson Penguin : Linux version 2.4.1 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
supermount
This email was delivered to you by The Free Internet, a Business Online Group company. http://www.thefreeinternet.net --- hello, i am fairly new to linux, i need it's fast number crunching powers for my research... and i have only recently begun to have a look at the kernel (i believe every workman should know his tools). but i have noticed that supermount is not a standard part of the project, is there any reason why this is? is it due to man power? i would have been less shocked by the absense of other features in the kernel such as sound and radio support, supermount seems to me to be essential in any operating system. i apologise if this is a very silly question or if i have posted this question in the wrong place, but please excuse me, im new to this whole world. and keep up the good work, i wish i knew more about the whole thing so i could contribute something. Sam, Ireland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Bug in 3c905 driver.
Just a note... This card get's detected twofold by the plain 2.4.5 kernel. It get's listed twice under both lspci and during the kernel boot sequence on a HP LHr3 system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: all processes waiting in TASK_UNINTERRUPTIBLE state
>[EMAIL PROTECTED] said: >> I am running in to a problem, seemingly a deadlock situation, where >> almost all the processes end up in the TASK_UNINTERRUPTIBLE state. >> All the process eventually stop responding, including login shell, no >> screen updates, keyboard etc. Can ping and sysrq key works. I >> traced the tasks through sysrq-t key. The processors are in the idle >> state. Tasks all seem to get stuck in the __wait_on_page or >> __lock_page. > >I've seen this under UML, Rik van Riel has seen it on a physical box, and we >suspect that they're the same problem (i.e. mine isn't a UML-specific bug). Can you give more details? Was there an aic7xxx scsi driver on the box? run_task_queue(&tq_disk) should eventually unlock those pages but they remain locked. I am trying to narrow it down to fs/buffer code or the SCSI driver aic7xxx in my case. Thanks. /bulent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
supermount
This email was delivered to you by The Free Internet, a Business Online Group company. http://www.thefreeinternet.net --- hello, i have only been using linux for about a year, i am a physicist and i need its fast number crunching for my programs, i have recently become interrested in the kernel (i believe everyone should have some understanding of their tools), i have noticed supermount is not a standard part of this project, is there a good reason why this is? i apologise if this is a very silly question as i am sure it is, but it really does seem to me to be an essential feature, are there any plans to include it as a standard feature or is this due to man-power? i know patches do exist out there (all beit, really hard to find for recent 2.4.5) anyways, keep up the good work, i wish i knew enough about the whole thing to help out in some way, Sam, Ireland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Making a module 2.4 compatible
** Reply to message from James Lamanna <[EMAIL PROTECTED]> on Sat, 23 Jun 2001 22:10:58 -0700 > It would be nice to have it working under 2.4, so is there someplace > that outlines some of the major things that would have changed so I can > update the module accordingly? Unfortunately, no. But if it turns out I'm wrong, please let me know what you find. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP+USB still crashes in 2.4.6-pre5
On Sun, Jun 24, 2001 at 01:52:37PM +0100, Alan Cox wrote: > > Just wanted people to know that the same problem I reported about 2.4.4 a > > while back is still present in 2.4.6-pre6 (hard crash when doing "cat > > whatever > /dev/dsp1" where /dev/dsp1 is an external USB audio device, where > > "hard crash" means a freeze followed by "wait on irq" message as reported > > earlier). > > Does this happen on 2.4.5-ac kernel as well ? The same problem is present in -ac18. //jb - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: loop device broken in 2.4.6-pre5
[EMAIL PROTECTED] wrote: > From: Jari Ruusu <[EMAIL PROTECTED]> > > File backed loop device on 4k block size ext2 filesystem: > > # dd if=/dev/zero of=file1 bs=1024 count=10 > 10+0 records in > 10+0 records out > # losetup /dev/loop0 file1 > # dd if=/dev/zero of=/dev/loop0 bs=1024 count=10 conv=notrunc > dd: /dev/loop0: No space left on device > 9+0 records in > 8+0 records out > # tune2fs -l /dev/hda1 2>&1| grep "Block size" > Block size: 4096 > # uname -a > Linux debian 2.4.6-pre5 #1 Thu Jun 21 14:27:25 EEST 2001 i686 unknown > > Stock 2.4.5 and 2.4.5-ac15 don't have this problem. > > I am not sure there is an error here. How about: dd if=/dev/hda1 of=disk.img bs=1k mount disk.img /mnt/d1 -o loop If the filesystem on hda1 happens to use the last 2k of the partition, and the partition size is 2k mod 4k, then I get a non-working disk.img if I don't pad the disk.img file with another 2k. And then I might trip up the "how big is this partition" code in the fs-driver Roger. -- ** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2137555 ** *-- BitWizard writes Linux device drivers for any device you may have! --* * There are old pilots, and there are bold pilots. * There are also old, bald pilots. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Thrashing WITHOUT swap.
On Monday 25 June 2001 18:16, Colonel wrote: > In clouddancer.list.kernel, you wrote: > >Further to that, I followed Alan's lead and installed xfce. My laptop, > > which was really suffering under Gnome with 64 meg (much more so under > > KDE) is suddenly light on its feet. Not to mention that it built from > > source in under 10 minutes and installed with zero 'interesting > > problems'. > > > >After another year of optimizing the kernel to handle bloatware better, > > and at the same time encouraging the 'big desktop' side of Linux to > > follow the lead of these lightweight alternatives[1] we will be looking > > pretty good. > > Had you tried fvwm-1.24r (the original) ? It was designed long ago to > be lean and fast on the desktop. I know it whips KDE. Yes, I did. It's even faster than xfce but there's one problem: it just isn't very much like a modern desktop. xfce is, to a surprising degree, like a modern desktop. It's roughly equivalent to W95 I'd say - more sophisticated in some areas, less in others. Oh, did I mention I haven't run into a bug yet? It's true. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: AMD thunderbird oops
Have you considered to change your dimm at all? If they are bugged they should be under warranty. Luigi On Mon, 25 Jun 2001 [EMAIL PROTECTED] wrote: > Thanks, > I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4" fan >in the case. (real nice case). > > I think it is the memory, as yesterday my gcc was bombing with 'internel >compiler error', which is usually a good mem tester. So I started setting mem=64m >and things worked better and the install went all the way through. I think I need to >slow my drams down a bit or add some delay in the bios settings. > >The oops says something like 'kernel null pointer at address 0x00'. How do I >'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am >forced to reboot and manually run e2fsck? > > Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message >that says Error 'missing seperator'. What does that mean? It stops in the >drivers/net dir when I get this message? > > Thanks > Joe > > Alan Cox <[EMAIL PROTECTED]> wrote: > > > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) >processor / 512Meg of RAM, and an Asus kt7a motherboard. > > > It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but >keep getting these oopses.. > > > > I also get these same problems while trying to install RH 7.1 > > > > Anyone know is this a supported processor / MB and has anyone had these problems? > > Random oopses normally indicate faulty board cpu or ram (and the fault may > even just be overheating or dimms not in the sockets cleanly). I doubt its > the board design or model that is the problem, you probably jut have a faulty > component somewhere if its oopsing randomly even during installs and stuff > > memtest86, and heatsink compound may be your best friends > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > 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] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: For comment: draft BIOS use document for the kernel
** Reply to message from Eric W. Biederman <[EMAIL PROTECTED]> on 23 Jun 2001 14:26:32 -0600 > Pretty decent. It misses a lot of hardware details that we still > depend on the BIOS to reliably setup for us. You're right, it does. I think that information should be added. It's a way for BIOS programmers to know whether or not their BIOS is missing anything obvious. -- Timur Tabi - [EMAIL PROTECTED] Interactive Silicon - http://www.interactivesi.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Thrashing WITHOUT swap.
On 25 Jun 2001, Xavier Bestel wrote: > On 24 Jun 2001 22:36:25 +0100, Alan Cox wrote: > > > recompiled it yet). I have a 140 mb swap partition set up but at the time > > > this happened it was OFF. I was (still am) running X + twm + two xterms > > > > > > top gives me: > > > mem: 62144k av, 61180k used, 956k free, 0k shrd, 76 buff, 2636 cached > > > swap: 0k av, 0k used, 0k free [as expected] > > > > Not as expected - 0k used 0k free - you have no swap > > That's what he said. *WITHOUT* swap. :)) yeah, exactly what Alan said. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: AMD thunderbird oops
Thanks, I have a heat sink and it is huge about 2 inches, plus fan. Plus another 4" fan in the case. (real nice case). I think it is the memory, as yesterday my gcc was bombing with 'internel compiler error', which is usually a good mem tester. So I started setting mem=64m and things worked better and the install went all the way through. I think I need to slow my drams down a bit or add some delay in the bios settings. The oops says something like 'kernel null pointer at address 0x00'. How do I 'catch' the output of an oops when the filesystem goes and I get ext2fs errors and am forced to reboot and manually run e2fsck? Lastly with the mem=64M or mem=128M when I do a make dep, I get an error message that says Error 'missing seperator'. What does that mean? It stops in the drivers/net dir when I get this message? Thanks Joe Alan Cox <[EMAIL PROTECTED]> wrote: > > I just upgradede my system to an 1200Mhz AMD Athlon Thundirbird (266Mhz FSB) >processor / 512Meg of RAM, and an Asus kt7a motherboard. > > It is oppsing left and right. I recompiled the kernel with Athelon as the CPU but >keep getting these oopses.. > > I also get these same problems while trying to install RH 7.1 > > Anyone know is this a supported processor / MB and has anyone had these problems? Random oopses normally indicate faulty board cpu or ram (and the fault may even just be overheating or dimms not in the sockets cleanly). I doubt its the board design or model that is the problem, you probably jut have a faulty component somewhere if its oopsing randomly even during installs and stuff memtest86, and heatsink compound may be your best friends - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What are the VM motivations??
On Monday 25 June 2001 17:46, Colonel wrote: > >> POST IT. Give the rest of us some clues and the opportunity to check > >> evaluator's replies. > > > >Well, if you try that strategy you'll find you never get around to posting > > it because you'll be too worried about getting it right. The point is > > not to get it right, it's to get a starting point down on (virtual) > > paper. I'd strongly suggest passing something like that around for > > comment privately first. > > Well, it does seem that some ego is involved here... Not in this case. Do it whichever way you want, the point is: do it (don't just talk about it) -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Re: Thrashing WITHOUT swap.
In clouddancer.list.kernel, you wrote: > >Further to that, I followed Alan's lead and installed xfce. My laptop, which >was really suffering under Gnome with 64 meg (much more so under KDE) is >suddenly light on its feet. Not to mention that it built from source in >under 10 minutes and installed with zero 'interesting problems'. > >After another year of optimizing the kernel to handle bloatware better, and >at the same time encouraging the 'big desktop' side of Linux to follow the >lead of these lightweight alternatives[1] we will be looking pretty good. Had you tried fvwm-1.24r (the original) ? It was designed long ago to be lean and fast on the desktop. I know it whips KDE. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.5 crash
In clouddancer.list.kernel, you wrote: > >Hi all, > >Haven't been on this list for a while, and don't really know if this is the >right place for this message... If not, pls let me know. >... >Hope you guys can do something with this message! Nope. You need to run it thru ksymoops before the wizard's crystal balls will clear sufficiently to help. Look in /usr/src/linux/scripts for clues. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATE] Directory index for ext2
On Monday 25 June 2001 11:46, Tony Gale wrote: > After some testing, removing the grsecurity patch seems to have solved > the disappearing-free-space problem. Now just need to find out why. > > On 20 Jun 2001 18:58:43 +0200, Daniel Phillips wrote: > > On Wednesday 20 June 2001 16:59, Tony Gale wrote: > > > The main problem I have with this is that e2fsck doesn't know how to > > > deal with it - at least I haven't found a version that will. This makes > > > it rather difficult to use, especially for your root fs. > > > > Good, the file format isn't finalized, this is only recommended for use > > on a test partition. > > It was a test partition, just happended to be a root one. AFAIAA, isn't > the fact that the file format may change irrelevant. You want people to > test this stuff or not? If it's not tested on a root fs then how do you > know there won't be any problems. > > Sorry, but when someone reports a problem, and then you say, well don't > test it like that then, it is really not acceptable. Sure, if your root partition is expendable, by all means go ahead. Ted has already offered to start the required changes to e2fsck, which reminds me, I have to send the promised docs. For now, just use normal fsck and it will (in theory) turn the directory indexes back into normal file blocks, and have no effect on inodes. Lets take advantage of the opportunity to test that feature. The new improved e2fsck should be capable of re-adding the indexes, so we'll get to test that too ;-) Lets continue this privately and see what's going on with your inode leak. -- Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/