Re: es1371 and recent kernels (thanks)
:-> "Kipp" == Kipp Cannon <[EMAIL PROTECTED]> writes: > Hi, > I have an es1371 based sound card (Creative Ensoniq Audio-PCI something > whatever) and it has worked fine for me with both 2.4.2 and 2.4.3. It > looks like other people have already responded to your message but if you > would like any information (like the contents of my .config file for my > kernel build) just let me know. > -Kipp Thanks to everyone that answered my question. It seems that I was misled by the poor mixer and in all the testing that I did I ended up plugging the wrong connector. Ciao Pf -- --- Pierfrancesco Caci |System Administrator @ seabone.net [EMAIL PROTECTED] | Telecom Italia S.p.A. - International Operations Linux paperino 2.4.5 #1 Tue Jun 12 11:33:43 CEST 2001 i686 unknown - 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/
Question about signal handling
Hopefully I'm not asking a really stupid question here, but...
When setting up a signal handler, using sa_handler, there is a
quasi-documented 2nd parameter of 'struct context ctx' passed to the signal
handler. This seems to work on 2.2.12, 2.2.18, and 2.4.5-ac2. According to
various documents, when using sa_siginfo (and setting SA_SIGINFO), the third
parameter to the handler is defined as a 'void *', but actually passes a
'ucontext_t' data type. Which is not defined in any kernel code, except for
the sparc64 branch. Casting this to a 'struct context' or a 'struct context
*' doesn't seem to achieve the desired results on any of the three kernels I
tested.
Google searches indicate different things. POSIX 1 compliance says it
should be a 'ucontext_t *'
(www.opengroup.org/onlinepubs/007908799/xsh/sigaction.html+sigcontext+siginf
o_t+sigaction=en=lang_en) (I realize that's the Open standard, but the
comments at the bottom talk about POSIX compliance). Other searches say it
returns as a 'struct context *'.
I tried following the code through the kernel, but I'm not familiar enough
with yet to really understand how it's getting scheduled, and exactly which
parameters are getting passed back.
What is the correct behavior supposed to be? And if using sa_siginfo, how
does one get at the context parameters to find the EIP the fault occurred
at?
Here's a sample bit of code I used for testing. Leaving #define SIGACTION
demonstrates the third parameter not (seemingly) being passed as a context
pointer, #undef demonstrates the sa_handler 2 paramter handler, which
returns a correct context.
#include
#include
#include
#include
#define SIGACTION
#ifdef SIGACTION
void fSegvHandler (int sigNo, siginfo_t *si, void *p)
{
struct sigcontext *context = (struct sigcontext *) p;
#else
void fSegvHandler (int sigNo, void *p)
{
struct sigcontext *context = (struct sigcontext *)
#endif
printf ("\nContext: %08X\n",context);
fflush (stdout);
printf ("gs: %04X\tfs: %04X\tes: %04X\tds: %04X\n"
"edi: %08X\tesi: %08X\tebp: %04X\tesp: %04X\n"
"ebx: %08X\tedx: %08X\tecx: %08X\teax: %08X\n"
"trap: %d\terr: %d\teip: %08X\tcs: %04X\n"
"flag: %08X\tSP: %08X\tss: %04X\tcr2: %08X\n",
context->gs, context->fs, context->es, context->ds,
context->edi, context->esi, context->ebp, context->esp,
context->ebx, context->edx, context->ecx, context->eax,
context->trapno, context->err, context->eip, context->cs,
context->eflags, context->esp_at_signal, context->ss,
context->cr2);
fflush (stdout);
exit (0);
}
int main (int argc, char **argv)
{
struct sigaction sSegvHdl;
sigemptyset (_mask);
sigaddset (_mask, SIGSEGV);
#ifdef SIGACTION
sSegvHdl.sa_flags = SA_SIGINFO | SA_ONESHOT;
sSegvHdl.sa_sigaction = fSegvHandler;
#else
sSegvHdl.sa_flags = SA_ONESHOT;
sSegvHdl.sa_handler = fSegvHandler;
#endif
if (sigaction (SIGSEGV, , NULL))
perror ("sigaction");
else
*(char *) 0x0 = 0x01;
}
-- John
-
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/
Are You In Need Of A Lifestyle Change...
You have the opportunity to partake in the most extraordinary and powerful wealth building program available! This information has never been offered to the general public, you have been given the opportunity to take a close look. If you're skeptical, that's okay. Just make the call and see for yourself. My job is to inform you, your job is to make your own decision. This is not multi-level marketing, nor is it a franchise, we will teach you how to amass wealth, protect that wealth, and show you how to make that wealth work for you, rather then you working for it. You Own It To Yourself And Your Family To Give Our Program Serious Consideration I invite you to call me for more details at 1-800-995-0796 EXT 7071 This is a free 2 minute recording, so call right now! Prosperous regards, Paul This Is Not Multi Level Marketing/Serious Inquiries Only MEMBER International Internet Watchdog Group - 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/
[OT] Re: inetd missing
Blesson Paul wrote: > hi > I just brought a CD of RedHat 7. Unfortunately I > couldn't find the inetd rpm. wheather it is missing or it is in any other > name It's xinetd - BTW You might think about RH 7.1 since 7.0 was the end of the line for the legacy 2.2. kernel - cu jjs - 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/
inetd missing
hi I just brought a CD of RedHat 7. Unfortunately I couldn't find the inetd rpm. wheather it is missing or it is in any other name by Blesson Get free email and a permanent address at http://www.netaddress.com/?N=1 - 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: obsolete code must die
On Wed, 13 Jun 2001, Stephen Satchell wrote: > At 12:24 AM 6/14/01 -0300, Rik van Riel wrote: > >Everything you propose to get rid of are DRIVERS. They > >do NOT complicate the core kernel, do NOT introduce bugs > >in the core kernel and have absolutely NOTHING to do with > >how simple or maintainable the core kernel is. > > Not quite. There were two non-driver suggestions that the man did > make: remove 386/486 support and remove floating-point emulation > support. Both are bad for the embedded-systems space, because the 486 > is still used there widely. Both are wy outside the core of the kernel, though. > Are all the bus support code exclusively in drivers, or is there > something compiled into the nucleus for start-up? They're compiled into the nucleus (if you want to), but they're in no way clogging up the source code of the core kernel. 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/
initial ramdisk failure
I have been trying for a while now, without luck, to get a kernel with the SGI XFS system to boot as modules. I do fine if I make all scsi and XFS as non-modules, but modules fail for both scsi and XFS (I can make one or the other modular at a time, or both, it fails). According to what I see, this should not be happening, but it is. All messages indicate it was successful. I can also take the initial ramdisk image and gzip, and create a file that I mount via loopback to actually view the items it contains...no surprises, it has what it should have. But lilo is not using it (the messages from lilo claim to, but proof is in the failure). I'm going to list my output below, but the question will be, for an SMP scsi aic7xxx system, noapic, with ext2 compiled in, and /boot on its own ext2 partition (root is XFS), how is it possible that this output lies and does not install scsi or XFS modules? Big note: label with -2 is successful and has no modules; label with -3 fails, if any part of filesystem XFS or scsi is modular, and otherwise, there are no kernel configuration differences. Also, the "ramdisk_size" argument of the relevant kernel is due to the size of XFS, just to be sure. The output: lilo.conf: boot=/dev/sda map=/boot/map install=/boot/boot.b prompt timeout=50 message=/boot/message linear vga=0x030c default=2.4.6-p1-xfs-2 backup=boot.backup.when-2.4.6-pre1-xfs-3 # FAILS, modular. image=/boot/vmlinuz-2.4.6-pre1-xfs-3 label=2.4.6-p1-xfs-3 initrd=/boot/ir-2.4.6-p1-xfs-3.img read-only root=/dev/sda6 append="noapic ramdisk_size=16000" # WORKS, no relevant modules, despite a ramdisk. image=/boot/vmlinuz-2.4.6-pre1-xfs-2 label=2.4.6-p1-xfs-2 initrd=/boot/initrd-2.4.6-pre1-xfs-2.img read-only root=/dev/sda6 append="noapic" Creating the ramdisk (tried both with SGI's mkinitrd.xfs, as well as regular mkinitrd): mkinitrd \ -v \ -f \ --preload pagebuf \ --preload xfs_support \ --preload xfs \ --with=scsi_mod \ --with=sd_mod \ --with=aic7xxx \ /boot/ir-2.4.6-p1-xfs-3.img \ 2.4.6-pre1-xfs-3 The output of mkinitrd: Using modules: ./kernel/fs/pagebuf/pagebuf.o ./kernel/fs/xfs_support/xfs_support.o ./kernel/fs/xfs/xfs.o ./kernel/drivers/scsi/scsi_mod.o ./kernel/drivers/scsi/sd_mod.o ./kernel/drivers/scsi/aic7xxx/aic7xxx.o Using loopback device /dev/loop0 /sbin/nash -> /tmp/initrd.sXOMy4/bin/nash /sbin/insmod.static -> /tmp/initrd.sXOMy4/bin/insmod `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/pagebuf/pagebuf.o' -> `/tmp/initrd.sXOMy4/lib/pagebuf.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs_support/xfs_support.o' -> `/tmp/initrd.sXOMy4/lib/xfs_support.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/fs/xfs/xfs.o' -> `/tmp/initrd.sXOMy4/lib/xfs.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/scsi_mod.o' -> `/tmp/initrd.sXOMy4/lib/scsi_mod.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/sd_mod.o' -> `/tmp/initrd.sXOMy4/lib/sd_mod.o' `/lib/modules/2.4.6-pre1-xfs-3/./kernel/drivers/scsi/aic7xxx/aic7xxx.o' -> `/tmp/initrd.sXOMy4/lib/aic7xxx.o' Loading module pagebuf with options Loading module xfs_support with options Loading module xfs with options Loading module scsi_mod with options Loading module sd_mod with options Loading module aic7xxx with options The output of lilo -v -v: # lilo -v -v LILO version 21.4-4, Copyright (C) 1992-1998 Werner Almesberger 'lba32' extensions Copyright (C) 1999,2000 John Coffman Reading boot sector from /dev/sda Merging with /boot/boot.b Secondary loader: 11 sectors. Mapping message file /boot/message Message: 46 sectors. Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-3 Setup length is 9 sectors. Mapped 1607 sectors. Mapping RAM disk /boot/ir-2.4.6-p1-xfs-3.img RAM disk: 1304 sectors. Added 2.4.6-p1-xfs-3 Boot image: /boot/vmlinuz-2.4.6-pre1-xfs-2 Setup length is 9 sectors. Mapped 2274 sectors. Mapping RAM disk /boot/initrd-2.4.6-pre1-xfs-2.img RAM disk: 500 sectors. Added 2.4.6-p1-xfs-2 * boot.backup.when-2.4.6-pre1-xfs-3 exists - no backup copy made. Map file size: 34304 bytes. Writing boot sector. NOTE: It explicitly states "Mapping RAM disk /boot/ir-2.4.6-p1-xfs-3.img", the relevant ramdisk. It lied. How can it be? I've been going at this for a couple of weeks now with no success. After using gzip -dc on the .img, and mounting it via loopback, here is the content of linuxrc: #!/bin/nash echo "Loading pagebuf module" insmod /lib/pagebuf.o echo "Loading xfs_support module" insmod /lib/xfs_support.o echo "Loading xfs module" insmod /lib/xfs.o echo "Loading scsi_mod module" insmod /lib/scsi_mod.o echo "Loading sd_mod module" insmod /lib/sd_mod.o echo "Loading aic7xxx module" insmod /lib/aic7xxx.o Here is the tree of the whole initial ramdisk from loopback mount: . |-- bin | |-- insmod | `-- nash |-- dev | |-- console | |-- null | |-- ram | |-- systty | |-- tty1 | |-- tty2 | |-- tty3 | `-- tty4 |-- etc |-- lib | |-- aic7xxx.o | |-- pagebuf.o |
Re: obsolete code must die
At 12:24 AM 6/14/01 -0300, Rik van Riel wrote: >Everything you propose to get rid of are DRIVERS. They >do NOT complicate the core kernel, do NOT introduce bugs >in the core kernel and have absolutely NOTHING to do with >how simple or maintainable the core kernel is. Not quite. There were two non-driver suggestions that the man did make: remove 386/486 support and remove floating-point emulation support. Both are bad for the embedded-systems space, because the 486 is still used there widely. Are all the bus support code exclusively in drivers, or is there something compiled into the nucleus for start-up? I didn't see your "don't feed the troll" sign before... Satch - 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: obsolete code must die
Em Wed, Jun 13, 2001 at 09:55:54PM -0400, Horst von Brand escreveu: > "Daniel" <[EMAIL PROTECTED]> said: > > I really think doing a clean up is worthwhile. Maybe while looking for stuff > > to clean up we'll even be able to better comment the existing code. Any > > other features people would like to get rid of? Any comments or suggestions? > > I'd love to start a good discussion about this going so please send me your > > 2 cents. > > Try it, and come back with patches. hey, the KJP needs volunteers to tackle this bug/cleanup list: http://bazar.conectiva.com.br/~acme/TODO More info available at http://kernel-janitor.sourceforge.net/, the Stanford Checker also found bugs that have to be fixed (link provided in the KJP page), please help. As for what I want to get rid of? Bugs, getting rid of those would be excellent ;) - Arnaldo (the one that is porting a network stack to 2.4 that would warrant death penalty if Daniel was the judge ;) ) - 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/
tmscsim.o INQUIRY inconsistency in 2.2.19
Is this a known bug in tmscsim.o (2.0f, included with 2.2.19): I have the following devices (cat /proc/scsi/scsi) Attached devices: Host: scsi0 Channel: 00 Id: 00 Lun: 00 Vendor: SEAGATE Model: ST15230N Rev: 0638 Type: Direct-AccessANSI SCSI revision: 02 Host: scsi0 Channel: 00 Id: 04 Lun: 00 Vendor: TOSHIBA Model: CD-ROM XM-3601TA Rev: 0725 Type: CD-ROM ANSI SCSI revision: 02 cat /proc/scsi/tmscsim/0 Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f 2000-12-20 SCSI Host Nr 0, AM53C974 Adapter Nr 0 IOPortBase 0xff00, IRQ 10 MaxID 7, MaxLUN 8, AdapterID 7, SelTimeout 250 ms, DelayReset 1 s TagMaxNum 16, Status 0x00, ACBFlag 0x00, GlitchEater 24 ns Statistics: Cmnds 257518, Cmnds not sent directly 25959, Out of SRB conds 0 Lost arbitrations 6240, Sel. connected 0, Connected: No Nr of attached devices: 2, Nr of DCBs: 2 Map of attached LUNs: 01 00 00 00 01 00 00 00 Idx ID LUN Prty Sync DsCn SndS TagQ NegoPeriod SyncSpeed SyncOffs MaxCmd 00 00 00 Yes Yes Yes Yes Yes 100 ns10.0 M 15 16 01 04 00 Yes Yes Yes Yes No236 ns 4.0 M 15 01 Commands in Queues: Query: 0: Often (but not always), on boot, I get Sync as "No" for the hard drive (Idx 0). Doing "echo 'inquiry 0' > 0" always fixes the problem after boot but for some reason, the driver doesn't (always) pick up on this at boot time. It doesn't seem to matter if it's a boot up from power-off or soft reboot. The drive, Seagate Hawk, support synchronous operation and sync negotiation. - John _ Get your FREE download of MSN Explorer at http://explorer.msn.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: obsolete code must die
"Daniel" <[EMAIL PROTECTED]> said: [...] > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. How much does this contribute? I guess the _truly_ i[34]86 dependent code is a few hundred lines, if that much. Besides, you would probably be surprised at the number of those machines in use. [...] > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc Just too bad that 2 out of my 4 machines at home are ISA only, this one is ISA/PCI; and of the servers at work a lowly P/155 (just ISA) is doing useful work as the connection point for modems. [...] > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. No non-paralell printers in sight for me. Some 2 dozen printers in all. [...] > I really think doing a clean up is worthwhile. Maybe while looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or suggestions? > I'd love to start a good discussion about this going so please send me your > 2 cents. Try it, and come back with patches. -- 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: Eye2Eye a hope for Promise to Join Linux
Andre Hedrick <[EMAIL PROTECTED]> said: > Greetings Craig, [...] Bravissimo! -- 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: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: OK, after my earlier troll posting, lets go over Daniel's reasons point by point. Well actually, all of these points fit in one argument. > -- Getting rid of old code can help simplify the kernel. This means > less chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. Everything you propose to get rid of are DRIVERS. They do NOT complicate the core kernel, do NOT introduce bugs in the core kernel and have absolutely NOTHING to do with how simple or maintainable the core kernel is. All of the arguments you give above are irrelevant to the things you propose to have removed from the kernel. > -- If someone really needs support for this junk, they will always > have the option of using the 2.0.x, 2.2.x or 2.4.x series. They have that option NOW, but in the future people may no longer be interested in doing essential things like security updates or network protocol updates to older kernels. Also, forcing people to use these older kernels will only ADD to the maintenance problems of the Linux kernel, instead of making them less ... since then we'd have to release security and network protocol updates against more kernel versions. It would also make it impossible for people to combine new and old hardware in one machine. Think of ham radio operators or physics people who have their own home-brewn hardware for packet radio or data acquisition. It's not your arguments or the things you propose that make me think you're a troll. It's the fact that the things you propose are completely unrelated to the arguments you give for them ;) 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: 2.4.6-pre2, pre3 VM Behavior
On Wed, 13 Jun 2001, Tom Sightler wrote: > Quoting Rik van Riel <[EMAIL PROTECTED]>: > > > After the initial burst, the system should stabilise, > > starting the writeout of pages before we run low on > > memory. How to handle the initial burst is something > > I haven't figured out yet ... ;) > > Well, at least I know that this is expected with the VM, although I do > still think this is bad behavior. If my disk is idle why would I wait > until I have greater than 100MB of data to write before I finally > start actually moving some data to disk? The file _could_ be a temporary file, which gets removed before we'd get around to writing it to disk. Sure, the chances of this happening with a single file are close to zero, but having 100MB from 200 different temp files on a shell server isn't unreasonable to expect. > > This is due to this smarter handling of the flushing of > > dirty pages and due to a more subtle bug where the system > > ended up doing synchronous IO on too many pages, whereas > > now it only does synchronous IO on _1_ page per scan ;) > > And this is definately a noticeable fix, thanks for your continued > work. I know it's hard to get everything balanced out right, and I > only wrote this email to describe some behavior I was seeing and make > sure it was expected in the current VM. You've let me know that it > is, and it's really minor compared to problems some of the earlier > kernels had. I'll be sure to keep this problem in mind. I really want to fix it, I just haven't figured out how yet ;) Maybe we should just see if anything in the first few MB of inactive pages was freeable, limiting the first scan to something like 1 or maybe even 5 MB maximum (freepages.min? freepages.high?) and flushing as soon as we find more unfreeable pages than that ? Maybe another solution with bdflush tuning ? I'll send a patch as soon as I figure this one out... 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: obsolete code must die
i have a corvus 20meg drive and a xebec 10meg that both still spin up. those are from mid to late 80s. i have seagate hawks from '94 that still work, but quantums from the same period are all dead. the difference is that newer drives have much tighter tolerances and are much more sensitive to dust. it varies from drive to drive, of course. On Thu, Jun 14, 2001 at 11:41:15AM +1000, David Luyer wrote: > Even old Eagle drives from 1988 still spin up... given you have to flick the > starter switch to spin them up half a dozen times, but they still work... > seems they don't make disk drives like they used to. -- Tom Vier <[EMAIL PROTECTED]> DSA Key id 0x27371A2C - 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: Download process for a "split kernel" (was: obsolete code must die)
> > Or as a simpler design, something like; > > * a copy of the kernel maintained in a CVS tree > * kernel download would pull down: > * the build script > * a file containing the list of filenames depended on by > each config option > * build script builds the config and then cvs updates the file list > and the files for each config option in question to the version as > tagged in the build script > > Someone could relatively easily maintain this separate to all the kernel > developers, and it would mean only ever having to download files you were > actually using. OR 50 % of kernel size is from /linux/drivers 25 % of kernel size is from machine dependent /linux/arch/ and /linux/include/ If we are able to divide Linux tree in such a way that everyone can download it from from their personnal modems and enjoy linux. may be i am wrong . But i love downloading whole kernel and i usually refer different architectures. Thank you, Best Regards, Jaswinder. -- These are my opinions not 3Di. - 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/
Lecteur CD-ROM
Bonsoir,
Je vous décrirai le problème du mieux que je peux. Avant tout, je tiens
à souligner que, sous les mêmes configurations, le problème ne s'est produit
et reproduit que sur les kernels 2.4.X (kernels testés : 2.2.18, 2.2.19,
2.4.0, 2.4.3, 2.4.5).
J'ai en ma possession un CD-R (fait sous Windows 98) qui fonctionne sans
reproches. Absolument rien d'anormal ne se produit quand j'écris la ligne
suivante : "mount /dev/cdrom". Le problème survient quand j'essaye de
copier un fichier sur le disc dur. Le message suivant s'affiche :
hdb: command error: status=0x51 { DriveReady SeekComplete Error }
hdb: command error: error=0x54
end_request: I/O error, dev 03:40 (hdb), sector 14776
hdb: command error: status=0x51 { DriveReady SeekComplete Error }
hdb: command error: error=0x54
end_request: I/O error, dev 03:40 (hdb), sector 14780
cp: wumpscut - mortal highway.mp3: Input/output error
...
Je rappelle que ce problème n'est jamais arrivé sur aucuns des kernels 2.2.X
que j'ai compilé.
N.B. : je possède un ATAPI CDROM: LTN242F
Merci beaucoup
Michel
_
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.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: 2.4.6-pre2, pre3 VM Behavior
Quoting Mark Hahn <[EMAIL PROTECTED]>: > > 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb > Ethernet, > > close to wire speed). At this point Linux has yet to write the first > byte to > > disk. OK, this might be an exaggerated, but very little disk activity > has > > occured on my laptop. > > right. it could be that the VM scheduling stuff needs some way to > tell > whether the IO system is idle. that is, if there's no contention for > the disk, it might as well be less lazy about writebacks. That's exactly the way it seems. > > 2. Suddenly it's as if Linux says, "Damn, I've got a lot of data to > flush, > > maybe I should do that" then the hard drive light comes on solid for > several > > seconds. During this time the ftp transfer drops to about 1/5 of the > original > > speed. > > such a dramatic change could be the result of IDE misconfiguration; > is it safe to assume you have DMA or UDMA enabled? Yes, UDMA/33 is enabled and working on the drive (using hdparm -d 0 makes the problem way worse and my drive performs about 1/4 the speed). > > This was much less noticeable on a server with a much faster SCSI hard > disk > > subsystem as it took significantly less time to flush the information > to the > > is the SCSI disk actually faster (unlikley, for modern disks), or > is the SCSI controller simply busmastering, like DMA/UDMA IDE, > but wholly unlike PIO-mode IDE? First, lets be fair, we're comparing a UDMA/33 IDE drive in a 1 year old laptop (IBM Travelstar, if your interested) to a true SCSI Disk Subsystem with mirrored/striped Ultra160 SCSI disk connected via 64bit PCI/66Mhz bus, so yes, the SCSI subsystem is MUCH faster. Specific numbers: Laptop with TravelStar IDE HD Max sustained read: 16.5MB/s Server with Ultra160 SCSI disk array Max sustained read: >100MB/s That's a big difference. The Travelstar is probably only 5400RPM and is optimized for power savings, not speed, the SCSI subsystem has multiple 15000RPM in a striped/mirrored configuration for speed. Later, 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/
Download process for a "split kernel" (was: obsolete code must die)
> I agree that removing support for any hardware is a bad idea but I question > the idea of putting it all in one monolithic download (tar file). If we're > considering the concern for less developed nations with older hardware, > imagine how you would like to download the whole kernel with an old 2400 bps > modem. Not a fun thought. > > Would it make sense to create some sort of 'make config' script that > determines what you want in your kernel and then downloads only those > components? After all, with the constant release of new hardware, isn't a > 50MB kernel release not too far away? 100MB? This might actually make sense - a kernel composed of multiple versioned segments. A tool which works out dependencies of the options being selected, downloads the required parts if the latest versions of those parts are not already downloaded, and then builds the kernel (or could even build during the download, as soon as the build dependencies for each block of the kernel are satisfied, if you want to be fancy...). Or as a simpler design, something like; * a copy of the kernel maintained in a CVS tree * kernel download would pull down: * the build script * a file containing the list of filenames depended on by each config option * build script builds the config and then cvs updates the file list and the files for each config option in question to the version as tagged in the build script Someone could relatively easily maintain this separate to all the kernel developers, and it would mean only ever having to download files you were actually using. David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: obsolete code must die
Daniel wrote: > > Anyone concerned about the current size of the kernel source code? I am, and > I propose to start cleaning house on the x86 platform. I mean it's all very > well and good to keep adding features, but stuff needs to go if kernel > development is to move forward. Before listing the gunk I want to get rid > of, here's my justification for doing so: > -- Getting rid of old code can help simplify the kernel. This means less > chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. > -- If someone really needs support for this junk, they will always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? > > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. > > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. > > MFM/RLL/XT/ESDI hard drive support > Does anyone still *have* an RLL drive that works? At the very least get rid > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. This is completely wrong. USB is a hog, IEEE 1394 joysticks? Almost every sound card out there...modern...have game ports that are useful now. USB is an evolving and often broken standard. Your idea of obsolete is not completely wrong, but it is far too wrong to go about it this way. And printers or serial mice? D. Stimits, [EMAIL PROTECTED] > > a.out > Who needs it anymore. I love ELF. > > I really think doing a clean up is worthwhile. Maybe while looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or suggestions? > I'd love to start a good discussion about this going so please send me your > 2 cents. > > 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/ - 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: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: > -- Getting rid of old code can help simplify the kernel. This means less > chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. > -- If someone really needs support for this junk, they will always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. One of the things that makes linux great is being able to actually put all that old hardware to use. Heck, I know people who use Mac SE still (running BSD though .. but still same idea). Yeah, sure I can run older kernels. But what if I want say .. the new and improved VM that's available in say 2.6? What then? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [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/
Re: 2.4.6-pre2, pre3 VM Behavior
Quoting Rik van Riel <[EMAIL PROTECTED]>: > After the initial burst, the system should stabilise, > starting the writeout of pages before we run low on > memory. How to handle the initial burst is something > I haven't figured out yet ... ;) Well, at least I know that this is expected with the VM, although I do still think this is bad behavior. If my disk is idle why would I wait until I have greater than 100MB of data to write before I finally start actually moving some data to disk? > This is due to this smarter handling of the flushing of > dirty pages and due to a more subtle bug where the system > ended up doing synchronous IO on too many pages, whereas > now it only does synchronous IO on _1_ page per scan ;) And this is definately a noticeable fix, thanks for your continued work. I know it's hard to get everything balanced out right, and I only wrote this email to describe some behavior I was seeing and make sure it was expected in the current VM. You've let me know that it is, and it's really minor compared to problems some of the earlier kernels had. Later, 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: obsolete code must die
I agree that removing support for any hardware is a bad idea but I question the idea of putting it all in one monolithic download (tar file). If we're considering the concern for less developed nations with older hardware, imagine how you would like to download the whole kernel with an old 2400 bps modem. Not a fun thought. Would it make sense to create some sort of 'make config' script that determines what you want in your kernel and then downloads only those components? After all, with the constant release of new hardware, isn't a 50MB kernel release not too far away? 100MB? --Rainer > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Colonel > Sent: Thursday, June 14, 2001 10:32 AM > To: [EMAIL PROTECTED] > Subject: Re: obsolete code must die > > > In list.kernel, you wrote: > > >i think we are all missing the ball here: i am happy when i see driver > >support for a piece of hardware that i have _NEVER_ heard of and at most > >_ONE_ person uses it. why? it means more stuff works in linux. we > >dont need to defend how many people use hardware X. if you have X, good > >for you. if not, you dont care, but at least good for linux as a whole. > > Good Point! > > >lets stop fanning the flames and let this (Microsoft-using, as Rik > >pointed out) troll die off. > > Agreed, he made the filter already. But it was good for some laughs, > checking a few cobwebs and I really didn't see flames. Plus I got to > test my new mailing list archive. - 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: obsolete code must die
Obsolete code must die. Hardware support must live on. > > ISA, MCA, EISA device drivers > > If support for the buses is gone, there's no point in supporting devices for > > these buses. > > I am not certain if tis is a good idea, for the reason given above. (Not > certain about MCA and EISA though.) MCA is common for PS/2's, which are still around. > > MFM/RLL/XT/ESDI hard drive support > > Does anyone still *have* an RLL drive that works? At the very least get rid > > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > I am not certain how much this stuff is still used outside the US. The XT > driver still being around does surprise me though. (Will that even *work* > on modern hardware? I didn't think you could get that card to work on a > 386.) Could never get my OMTI 8627 ESDI controller to work under Linux when I tried. It works under DOS/Win, Xenix and VSTa though. These controllers were pseudo-common early 386 machines (before the 386sx and 386dx) built for Xenix. Surprisingly the old NEC ESDI drive still spins up, when most of the 1998 or 1999 Seagates/IBM drives are dead or dying and we've had close to an entire A1000 Sun disk unit fail to spin up -- the 'top-end' disks of today rarely seem to last more than 2-3 years (in that if you turn them off after 2-3 years of continual service and turn them back on 1/2 hr later, half of the drives which haven't spat out a drive head in the interim years will fail to spin up). Even old Eagle drives from 1988 still spin up... given you have to flick the starter switch to spin them up half a dozen times, but they still work... seems they don't make disk drives like they used to. David. -- David LuyerPhone: +61 3 9674 7525 Engineering Projects Manager P A C I F I C Fax: +61 3 9699 8693 Pacific Internet (Australia) I N T E R N E T Mobile: +61 4 2983 http://www.pacific.net.au/ NASDAQ: PCNTF - 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: obsolete code must die
In list.kernel, you wrote: >i think we are all missing the ball here: i am happy when i see driver >support for a piece of hardware that i have _NEVER_ heard of and at most >_ONE_ person uses it. why? it means more stuff works in linux. we >dont need to defend how many people use hardware X. if you have X, good >for you. if not, you dont care, but at least good for linux as a whole. Good Point! >lets stop fanning the flames and let this (Microsoft-using, as Rik >pointed out) troll die off. Agreed, he made the filter already. But it was good for some laughs, checking a few cobwebs and I really didn't see flames. Plus I got to test my new mailing list archive. - 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: obsolete code must die
Hi >-- a simpler, cleaner kernel will also be of more use in an academic >environment. >i386, i486 >The Pentium processor has been around since 1995. Support for these older >processors should go so we can focus on optimizations for the pentium and >better processors. >ISA bus, MCA bus, EISA bus >PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, >CONFIG_ISAPNP, etc > >ISA, MCA, EISA device drivers >If support for the buses is gone, there's no point in supporting devices for >these buses. i use all of the above and also require some of the new feature though you say good for academic in the UK most of the places are still running 486's as workstations when they come to though them out soon you wanna at least let the run a linux course with them first :) >parallel/serial/game ports >More controversial to remove this, since they are *still* in pretty wide >use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. these are possible in greater usage than you think. isdn cards still look like serial ports etc... scanner and where do you plug a joy stick in i have never even seen a usb joystick. hey i dont even have USB ports. though i do agree that there is alot of stuff there but its still mostly drivers. -- - Web: http://www.stev.org Mobile: +44 07779080838 E-Mail: [EMAIL PROTECTED] 2:20am up 14:45, 6 users, load average: 0.10, 0.18, 0.42 - 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: obsolete code must die
> >i386, i486 > >The Pentium processor has been around since 1995. Support for these older > > No. Both of my cheap on-site systems for occasional access are 486s. > Why would I spend money for a system that is hardly ever used? I have 386's that I still use. > >ISA bus, MCA bus, EISA bus > >PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > >CONFIG_ISAPNP, etc > > No. There are still plenty of unique ISA cards around. How about all the isa ne2000 around the world? > >MFM/RLL/XT/ESDI hard drive support > >Does anyone still *have* an RLL drive that works? At the very least get > > rid > > OK, I haven't seen one of these for nearly 10 years. My 386 have one of these. > >parallel/serial/game ports > >More controversial to remove this, since they are *still* in pretty wide > >use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. ow, I think that you are in the future :-) > Send me the funds to replace my laser printers please. I want it too. > >a.out > >Who needs it anymore. I love ELF. > > OK, everything that I had in a.out was converted within a year of > ELF's introduction. There are some non open source programs that are a.out... I want to continue to use Linux on my 386 Thanks Rafael Diniz Brazil - 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: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? hmm... what about processors like cris? The big brother of the processor in the cute net-enabled-webcam by axis? AFAIK it doesn't have an fpu, and people put a lot of work into getting support for it into 2.4. > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. Fine, but can you leave in support for my PAS16? > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. No real problem there... > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. Wow, thanks for leaving me with no way to console into my netra. Incidentally, (As if anyone appropriate is actually READING this thread), can people who make distributions PLEASE not assume there are 3 or 4 serial ports? I tried installing debian-sparc on my netra and init warnings about being unable to open the 3rd serial port make menus unreadable. > I really think doing a clean up is worthwhile. Maybe while looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or suggestions? > I'd love to start a good discussion about this going so please send me your > 2 cents. Yeah, can we please get rid of ext2? I mean, everyone's using reiserfs now, right? And what about making SMP mandatory? I mean, who only has *ONE* processor in a machine in 2001? And ide and scsi support... ram is so cheap now who needs disk? get rid of everything except ramdisk. tape drives? cd burners? obsolete. Plus the RIAA doesn't want cd burners anyway. Maybe you can get funding for 2.6 kernel development from them with this plan! Justin - 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: obsolete code must die
On 13 Jun 2001 19:22:38 -0700, Alan Olsen wrote: > On Wed, 13 Jun 2001, Daniel wrote: > > > ISA bus, MCA bus, EISA bus > > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > > CONFIG_ISAPNP, etc > > This I strongly disagree with. > > There are alot of ISA cards still in use. (I have a USR 56k voice/fax > modem that still works great. How many Sound Blaster 16 cards are still > being used? Lots, i would guess.) > i think we are all missing the ball here: i am happy when i see driver support for a piece of hardware that i have _NEVER_ heard of and at most _ONE_ person uses it. why? it means more stuff works in linux. we dont need to defend how many people use hardware X. if you have X, good for you. if not, you dont care, but at least good for linux as a whole. driver support does not effect me if i dont use said driver. in an ideal world, my kernel is super-small (ultra-optimized code) but the full kernel source is huge (lots of platform and driver support). lets stop fanning the flames and let this (Microsoft-using, as Rik pointed out) troll die off. -- Robert M. Love [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/
Re: obsolete code must die
Yo Daniel! On Wed, 13 Jun 2001, Daniel Dickman wrote: > What I'd like to know is this -- will support for the i386, say, ever go > away? What if the hardware is no longer in existence/used by anyone? will > support stay in the kernel? There is an aweful lot of embedded Linux using 386 and 486 class devices. Just look at all those cheap NAT boxes at Frys. RGDS GARY --- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 [EMAIL PROTECTED] Tel:+1(541)382-8588 Fax: +1(541)382-8676 - 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/
Fw: Delivery Status Notification (Failure)
Gee Andre, I guess people who use hotmail don't have an opinion you'd care to read? - Original Message - From: +ADw-postmaster+AEA-mail.hotmail.com+AD4- To: +ADw-thatlinuxguy+AEA-hotmail.com+AD4- Sent: Wednesday, June 13, 2001 8:12 PM Subject: Delivery Status Notification (Failure) +AD4- This is an automatically generated Delivery Status Notification. +AD4- +AD4- Delivery to the following recipients failed. +AD4- +AD4-andre+AEA-linux-ide.org +AD4- +AD4- +AD4- +AD4- ATT00063.dat Dear Mr. Lyons, I think it's very exciting to see someone from promise talking to the community. I think the most important thing to remember is that even if the company does not release source, people will reverse engineer the cards anyway - possibly not giving the best support to the hardware that could be given with GPL'd source. How does that make the product look? If I can buy a controller that is very well documented (like my Adaptec 2940) and will serve my needs, and has source, I (personally) will pick that card over a closed source product where I cannot update the binary only driver provided by the manufacturer. While I recognize that sometimes it's hard to get "suits" to understand this, I encourage you to try. :-) Along these lines, I'm wondering what your interest, and Promise's policy is about Interviews? I'm curious to get your companies views on Linux, and also yours - I run a small (VERY loose, VERY non-serious) website called http://www.geekizoid.com/ and while we mostly cover troll related net humor, we also are trying to branch out and do more serious stuff. The Interview (if you would agree to it) would be "Slashdot style" - we'd let the readership know you were willing to answer questions, and we'd then forward them to you - you would then answer the ones you wanted, and those answers, verbatim with no editing, would appear with the questions as asked. William Scott Lockwood III Geekizoid Webmaster - Original Message - From: "Craig Lyons" <[EMAIL PROTECTED]> To: "'Andre Hedrick'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 6:52 PM Subject: RE: Eye2Eye a hope for Promise to Join Linux > Hi, > > Andre and I did indeed have a nice conversation on the phone. Thank you > again for taking the time to talk with me and offering your assistance. As I > stated on the phone, we are making a large commitment of resources to > supporting Linux by releasing drivers and utilities for our products, > including the FastTrak. I know we have plans to release source for our Ultra > and SuperTrak series cards, but at this point I'm not sure that the way we > are going to be supporting FastTrak is what you would like to see. As I > said, while I cannot guarantee anything that I don't have the authority to > deliver, I will pass on your requests. I will try to be an advocate for > Promise in the Linux community, and an advocate for the Linux community to > Promise. If the company has concerns, I will let you know what they are, and > then maybe you can tell us if we are off-base with those concerns or not. > > I would invite anybody to contact me if you have any suggestions, any > requests, whatever. As I told Andre, I won't promise something I can't > personally deliver, but I will do whatever I can to help out. I'm also > trying to get a technical point of contact so that you don't have to deal > with a marketing weenie who doesn't understand half of what you're saying > ;). > > Regards, > > Craig > > > -Original Message- > From: Andre Hedrick [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 13, 2001 2:43 PM > To: Craig Lyons > Cc: [EMAIL PROTECTED] > Subject: Eye2Eye a hope for Promise to Join Linux > > > > Greetings Craig, > > I would like to publicly thank you for coming to the table of GNU/GPL with > an open perspective. After 90 minutes on the phone, of which 45 minutes > were me pointing out issues promblems and complaints w/ 20 minutes on ways > to work on solutions in the near and distant future and the listening to > your concerns and questions between my moments of interruption. > > The next conversion will not have the burst-in moments because it will be > in person or my cell battery will be fully charged. > > Since you have stated "I will not make promise, I can not keep" this is a > good thing and it will go a fair way to clean up messes from the past on > both sides. > > I look forward to Promise working with Linux in meaningful and productive > ways. > > Please reply and correct anything that is mistated by me or verify the > correctness. This will show an action of good-faith before all those > watching here. > > Respectfully, > > Andre Hedrick > Linux ATA Development > > - > 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: Eye2Eye a hope for Promise to Join Linux
Dear Mr. Lyons, I think it's very exciting to see someone from promise talking to the community. I think the most important thing to remember is that even if the company does not release source, people will reverse engineer the cards anyway - possibly not giving the best support to the hardware that could be given with GPL'd source. How does that make the product look? If I can buy a controller that is very well documented (like my Adaptec 2940) and will serve my needs, and has source, I (personally) will pick that card over a closed source product where I cannot update the binary only driver provided by the manufacturer. While I recognize that sometimes it's hard to get "suits" to understand this, I encourage you to try. :-) Along these lines, I'm wondering what your interest, and Promise's policy is about Interviews? I'm curious to get your companies views on Linux, and also yours - I run a small (VERY loose, VERY non-serious) website called http://www.geekizoid.com/ and while we mostly cover troll related net humor, we also are trying to branch out and do more serious stuff. The Interview (if you would agree to it) would be "Slashdot style" - we'd let the readership know you were willing to answer questions, and we'd then forward them to you - you would then answer the ones you wanted, and those answers, verbatim with no editing, would appear with the questions as asked. William Scott Lockwood III Geekizoid Webmaster - Original Message - From: "Craig Lyons" <[EMAIL PROTECTED]> To: "'Andre Hedrick'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 6:52 PM Subject: RE: Eye2Eye a hope for Promise to Join Linux > Hi, > > Andre and I did indeed have a nice conversation on the phone. Thank you > again for taking the time to talk with me and offering your assistance. As I > stated on the phone, we are making a large commitment of resources to > supporting Linux by releasing drivers and utilities for our products, > including the FastTrak. I know we have plans to release source for our Ultra > and SuperTrak series cards, but at this point I'm not sure that the way we > are going to be supporting FastTrak is what you would like to see. As I > said, while I cannot guarantee anything that I don't have the authority to > deliver, I will pass on your requests. I will try to be an advocate for > Promise in the Linux community, and an advocate for the Linux community to > Promise. If the company has concerns, I will let you know what they are, and > then maybe you can tell us if we are off-base with those concerns or not. > > I would invite anybody to contact me if you have any suggestions, any > requests, whatever. As I told Andre, I won't promise something I can't > personally deliver, but I will do whatever I can to help out. I'm also > trying to get a technical point of contact so that you don't have to deal > with a marketing weenie who doesn't understand half of what you're saying > ;). > > Regards, > > Craig > > > -Original Message- > From: Andre Hedrick [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, June 13, 2001 2:43 PM > To: Craig Lyons > Cc: [EMAIL PROTECTED] > Subject: Eye2Eye a hope for Promise to Join Linux > > > > Greetings Craig, > > I would like to publicly thank you for coming to the table of GNU/GPL with > an open perspective. After 90 minutes on the phone, of which 45 minutes > were me pointing out issues promblems and complaints w/ 20 minutes on ways > to work on solutions in the near and distant future and the listening to > your concerns and questions between my moments of interruption. > > The next conversion will not have the burst-in moments because it will be > in person or my cell battery will be fully charged. > > Since you have stated "I will not make promise, I can not keep" this is a > good thing and it will go a fair way to clean up messes from the past on > both sides. > > I look forward to Promise working with Linux in meaningful and productive > ways. > > Please reply and correct anything that is mistated by me or verify the > correctness. This will show an action of good-faith before all those > watching here. > > Respectfully, > > Andre Hedrick > Linux ATA Development > > - > 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: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: I agree that some clean up is needed. (The size of the kernel is getting HUGE. Back in the old days, we didn't have kernels larger than a few hundred kbytes. That is because we had to type in the kernel source from source written on papyrus.) > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. You are in a part of the world that can afford them. In Third World countries, however, Pentiums are not always the norm. You are cutting off a good chunk of the world here. > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? How does getting rid of math-emu effect compilation on other platforms? Not just Intel out there... > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc This I strongly disagree with. There are alot of ISA cards still in use. (I have a USR 56k voice/fax modem that still works great. How many Sound Blaster 16 cards are still being used? Lots, i would guess.) It may not be pretty, but it is still widely used. (Even in the US.) > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. I am not certain if tis is a good idea, for the reason given above. (Not certain about MCA and EISA though.) > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. I don't have an argument there, except when it has not been that way long. > MFM/RLL/XT/ESDI hard drive support > Does anyone still *have* an RLL drive that works? At the very least get rid > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) I am not certain how much this stuff is still used outside the US. The XT driver still being around does surprise me though. (Will that even *work* on modern hardware? I didn't think you could get that card to work on a 386.) > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. This is BAD idea. This sort of joystick was produced until reciently. They are still in use. You will piss off a bunch of gamers this way. (Yanking a gamer's joystick is never a good idea.) > a.out > Who needs it anymore. I love ELF. How much legacy code is still out there? How much will still run on 2.4? I don't see this one as a problem, but I expect that there are some special cases that will keep it alive. > I really think doing a clean up is worthwhile. Maybe while looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or suggestions? > I'd love to start a good discussion about this going so please send me your > 2 cents. I would like to see a clean up of the documentation. (As well as new docs written.) Getting an updated list of all the parameters that can be passed to the kernel would be a nice start. (The current list looks pretty old.) I do agree that some parts need to be cut off from the main tree. Maybe this clean-up should be a part of 2.5? 2.7? 6.6.6? [EMAIL PROTECTED] | Note to AOL users: for a quick shortcut to reply Alan Olsen| to my mail, just hit the ctrl, alt and del keys. "All power is derived from the barrel of a gnu." - Mao Tse Stallman - 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: obsolete code must die
On Thursday 14 June 2001 01:44, Daniel wrote: > -- If someone really needs support for this junk, they will always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > You mean you want 2.5+ series to just stop supporting all older hardware? > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > Allow me to disagree. There are still plenty of those machines around. Imagine how many of these are offering some kind of service somewhere on Internet... A 100MHz 486 is still a good machine, if your task is computing related and not "desktop" related (since most actual desktop systems are not happy with less than 64MB RAM and other features no commonly present on 486 machines ;). I have 486 at home and I intend to continue using it. > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices > for these buses. > Right now I'm listening to my mp3 music in my ESS ISA sound card. If I like to listen to music while I work and I have a sound card that works why the heck do I need to buy a new PCI one? > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. > Not so fast with these ones. And serial and parallel ports are sometimes very useful, especially if you deal with electronics and/or are involved in prototipe electronics and similar (although I'm trying to move to the much better USB port :) > I really think doing a clean up is worthwhile. Maybe while looking for > stuff to clean up we'll even be able to better comment the existing code. > Any other features people would like to get rid of? Any comments or > suggestions? I'd love to start a good discussion about this going so please > send me your 2 cents. > I surely agree that cleaning up old stuff is very important, but please agree that one of the strenghts of Linux is that you don't need so powerfull or so advanced hardware to do the jobs, as some commercial alternatives require, you can reuse some hardware that would be otherwise obsolete, so YOU SAVE SOME BUCKS. As a student, Radio Amateur and Electronics entusiast, many times I have to rely on old and surplus hardware since money resources are scarce. Linux lets me have fun, even with low resources. Thats the key to sucess IMO. regards Claudio - 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: obsolete code must die
As an end user who uses cheap laptops for firewalls, I'm pretty much against this. I've got 2.2.18, 2.4.4-ac8, and 2.4.4-ac12 installed as firewall machines on 486 laptops. Why should we (the collective Linux world, not me personnally, since I'm not a kernel developer) limit the class of machines people can run? In fact, this seems to be one of the appealing features of Linux, that it runs on any x86 hardware class with a MMU. It allows people to get involved in Linux without making a committment to buying a new PC until they know they like it, or buying a new HD to do a dual boot install to experiment. Laptops are a particular issue here, because many of the laptops people can obtain inexpensively ARE 386/486 class machines. I'm all for cleaning up the kernel code, but I think it would be better served by documentation, not by limiting the hardware that can be run. I can't speak authoritively on how much of the kernel code is processor specific, since GCC takes care of most of that. I do know there are sections that are affected by the processor selection, but I can't believe that it's a significantly large enough portion to justify ripping it out in the name of cleaning it up. I do agree with deleting obsolete code, but not obsoleting hardware so we CAN delete code. --John > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Daniel > Sent: Wednesday, June 13, 2001 20:44 PM > To: Linux kernel > Subject: obsolete code must die > > > Anyone concerned about the current size of the kernel source > code? I am, and > I propose to start cleaning house on the x86 platform. I mean > it's all very > well and good to keep adding features, but stuff needs to go if kernel > development is to move forward. Before listing the gunk I want to get rid > of, here's my justification for doing so: > -- Getting rid of old code can help simplify the kernel. This means less > chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. > -- If someone really needs support for this junk, they will > always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? > > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting > devices for > these buses. > > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. > > MFM/RLL/XT/ESDI hard drive support > Does anyone still *have* an RLL drive that works? At the very > least get rid > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. > > a.out > Who needs it anymore. I love ELF. > > I really think doing a clean up is worthwhile. Maybe while > looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or > suggestions? > I'd love to start a good discussion about this going so please > send me your > 2 cents. > > 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/ - 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: obsolete code must die
On Wed, 13 Jun 2001, Daniel Dickman wrote: > Thanks for your email. I am aware of the "traditions" of the > Linux kernel, and this is really why I wanted to start a > discussion going about this. OK, so you almost certainly ARE a troll: 1) proposing to remove support for hardware many of us use every day 2) on purpose going against tradition 3) replying private email back to the list 4) and all this using Microsoft Outlook ;) The hints pointing towards "troll, Troll, TROLL" are overwhelming. Lets stop the thread here. thanks, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: obsolete code must die
In list.kernel, you wrote: > >Anyone concerned about the current size of the kernel source code? I am, and No. Since you are up to date with the latest in everything, I cannot see why you would be concerned about a few megabytes in your gigabyte drives. >i386, i486 >The Pentium processor has been around since 1995. Support for these older No. Both of my cheap on-site systems for occasional access are 486s. Why would I spend money for a system that is hardly ever used? >ISA bus, MCA bus, EISA bus >PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, >CONFIG_ISAPNP, etc No. There are still plenty of unique ISA cards around. >MFM/RLL/XT/ESDI hard drive support >Does anyone still *have* an RLL drive that works? At the very least get rid OK, I haven't seen one of these for nearly 10 years. >parallel/serial/game ports >More controversial to remove this, since they are *still* in pretty wide >use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. Send me the funds to replace my laser printers please. >a.out >Who needs it anymore. I love ELF. OK, everything that I had in a.out was converted within a year of ELF's introduction. >I really think doing a clean up is worthwhile. Maybe while looking for stuff You left out all the old non-IDE CDROM drives. - 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: obsolete code must die
Hi Andrew, Thanks for your email. I am aware of the "traditions" of the Linux kernel, and this is really why I wanted to start a discussion going about this. Basically one of the things I am wondering is how complex the kernel code can grow to become. All I am proposing is that old features start becoming deprecated and eventually removed. What I'd like to know is this -- will support for the i386, say, ever go away? What if the hardware is no longer in existence/used by anyone? will support stay in the kernel? This is the main point I wanted to make, and I guess I should have been clearer about this. Daniel - Original Message - From: "Andrew Pimlott" <[EMAIL PROTECTED]> To: "Daniel" <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 8:47 PM Subject: Re: obsolete code must die > Do you realize how violently your suggestions conflict with the > goals, practices, and traditions of Linux? I don't mean any > offense, but you should really learn more about Linux development > before making broad suggestions. > > Andrew - 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: Mingetty gets tainted-memory bug in cahced_lookup() durring tty open
[1.] Intermittent tainted-mem error in mingetty in cached_lookup() in tty open code [2.] During bootup, mingetty got a tainted memory bug in cached_lookup() while doing some tty opening stuff; this has only happened once, and I don't know how to reproduce. [3.] tty [4.] Linux version 2.4.5-ac9 (root@kyoko) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) #2 Tue Jun 12 22:05:32 PDT 2001 [5.] kernel BUG at slab.c:1244! invalid operand: CPU:0 EIP:0010:[kmalloc+324/496] EFLAGS: 00010086 eax: 001b ebx: c1447768 ecx: 0001 edx: 1810 esi: cea5a000 edi: cea5a9aa ebp: 00012800 esp: cebffe24 ds: 0018 es: 0018 ss: 0018 Process mingetty (pid: 903, stackpage=cebff000) Stack: c02233ef 04dc cea5a000 1000 cea5a9aa 0246 cfeecd88 c01393f0 cfb72e04 cebffe80 c02cfdc0 0405 0004 c017bf0d 0c3c 0007 0004 c017cb85 0004 0004 cfeecd87 Call Trace: [cached_lookup+16/80] [alloc_tty_struct+13/48] [init_dev+133/1008] [vfs_follow_link+225/336] [tty_open+331/896] [path_walk+1778/2048] [do_page_fault+0/1168] [do_page_fault+378/1168] [devfs_open+198/416] [dentry_open+195/320] [filp_open+77/96] [getname+91/160] [sys_open+54/176] [system_call+51/56] Code: 0f 0b 58 8b 6b 10 5a 81 e5 00 04 00 00 74 4d b8 a5 c2 0f 17 Jun 13 18:29:49 kyoko kernel: Linux version 2.4.5-ac9 (root@kyoko) (gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-81)) #2 Tue Jun 12 22:05:32 PDT 2001 [6.] [7.] Using devfs mingetty version 0.9.4-10 [7.1] # sh scripts/ver_linux Linux kyoko 2.4.5-ac9 #2 Tue Jun 12 22:05:32 PDT 2001 i686 unknown Gnu C 2.96 Gnu make 3.79.1 binutils 2.10.91.0.2 util-linux 2.11e mount 2.9w modutils 2.4.2 e2fsprogs 1.19 reiserfsprogs 3.x.0b pcmcia-cs 3.0.14 PPP2.3.7 Linux C Library2.2.2 Dynamic linker (ldd) 2.2.2 Linux C++ Library 2.. Procps 2.0.7 Net-tools 1.60 Console-tools 1999.03.02 Sh-utils 2.0 Modules Loaded ipt_REJECT ipt_state ipt_LOG ipt_unclean iptable_mangle iptable_filter ip_nat_ftp ip_conntrack_ftp iptable_nat tulip es1371 soundcore ac97_codec vfat fat sr_mod cdrom [7.2] # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 6 model name : Celeron (Mendocino) stepping: 5 cpu MHz : 498.888 cache size : 128 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr bogomips: 996.14 [7.3] # cat /proc/modules ipt_REJECT 3104 3 (autoclean) ipt_state848 2 (autoclean) ipt_LOG 3568 14 (autoclean) ipt_unclean 6912 2 (autoclean) iptable_mangle 1968 0 (autoclean) (unused) iptable_filter 1968 0 (autoclean) (unused) ip_nat_ftp 3712 0 (unused) ip_conntrack_ftp3968 0 [ip_nat_ftp] iptable_nat20512 1 [ip_nat_ftp] tulip 38816 1 (autoclean) es1371 26800 0 soundcore 4080 4 [es1371] ac97_codec 8672 0 [es1371] vfat9232 0 (unused) fat31264 0 [vfat] sr_mod 12656 0 (autoclean) (unused) cdrom 28256 0 (autoclean) [sr_mod] [7.4] # cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 0170-0177 : ide1 01f0-01f7 : ide0 02f8-02ff : serial(auto) 0376-0376 : ide1 03c0-03df : vga+ 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0400-043f : Intel Corporation 82371AB PIIX4 ACPI 0440-045f : Intel Corporation 82371AB PIIX4 ACPI 0cf8-0cff : PCI conf1 d000-dfff : PCI Bus #01 d800-d8ff : ATI Technologies Inc 3D Rage Pro AGP 1X/2X e800-e8ff : Lite-On Communications Inc LNE100TX e800-e8ff : tulip ef00-ef3f : Ensoniq ES1371 [AudioPCI-97] ef00-ef3f : es1371 ef80-ef9f : Intel Corporation 82371AB PIIX4 USB ffa0-ffaf : Intel Corporation 82371AB PIIX4 IDE ffa0-ffa7 : ide0 ffa8-ffaf : ide1 # cat /proc/iomem -0009fbff : System RAM 0009fc00-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-0ffd : System RAM 0010-0021b055 : Kernel code 0021b056-0027217f : Kernel data 0ffe-0fff7fff : ACPI Tables 0fff8000-0fff : ACPI Non-volatile Storage f480-f48f : PCI Bus #01 f800-fbff : Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge fca0-feaf : PCI Bus #01 fd00-fdff : ATI
Re: obsolete code must die
Daniel wrote: > > Anyone concerned about the current size of the kernel source code? I am, and > I propose to start cleaning house on the x86 platform. I mean it's all very > well and good to keep adding features, but stuff needs to go if kernel > development is to move forward. Before listing the gunk I want to get rid > of, here's my justification for doing so: > -- Getting rid of old code can help simplify the kernel. This means less > chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. > -- If someone really needs support for this junk, they will always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? > > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. > > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. If you don't want it, don't build it into your kernel. -- Jeff Garzik | Andre the Giant has a posse. Building 1024| MandrakeSoft | - 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: obsolete code must die
Cleanup is a nice idea , but Linux should support old hardware and should not affect them in any way. Jaswinder. - Original Message - From: "Daniel" <[EMAIL PROTECTED]> To: "Linux kernel" <[EMAIL PROTECTED]> Sent: Wednesday, June 13, 2001 5:44 PM Subject: obsolete code must die > Anyone concerned about the current size of the kernel source code? I am, and > I propose to start cleaning house on the x86 platform. I mean it's all very > well and good to keep adding features, but stuff needs to go if kernel > development is to move forward. Before listing the gunk I want to get rid > of, here's my justification for doing so: > -- Getting rid of old code can help simplify the kernel. This means less > chance of bugs. > -- Simplifying the kernel means that it will be easier for newbies to > understand and perhaps contribute. > -- a simpler, cleaner kernel will also be of more use in an academic > environment. > -- a smaller kernel is easier to maintain and is easier to re-architect > should the need arise. > -- If someone really needs support for this junk, they will always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > > math-emu > If support for i386 and i486 is going away, then so should math emulation. > Every intel processor since the 486DX has an FPU unit built in. In fact > shouldn't FPU support be a userspace responsibility anyway? > > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices for > these buses. > > all code marked as CONFIG_OBSOLETE > Since we're cleaning house we may as well get rid of this stuff. > > MFM/RLL/XT/ESDI hard drive support > Does anyone still *have* an RLL drive that works? At the very least get rid > of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, > CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. > > a.out > Who needs it anymore. I love ELF. > > I really think doing a clean up is worthwhile. Maybe while looking for stuff > to clean up we'll even be able to better comment the existing code. Any > other features people would like to get rid of? Any comments or suggestions? > I'd love to start a good discussion about this going so please send me your > 2 cents. > > 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/ > - 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: obsolete code must die
On Wed, 13 Jun 2001, Daniel wrote: > So without further ado here're the features I want to get rid of: > > i386, i486 > math-emu > ISA bus, MCA bus, EISA bus > ISA, MCA, EISA device drivers > parallel/serial/game ports ++ | Please, | |don't feed | | the | | trolls.| ++ || || || \/ Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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: Eye2Eye a hope for Promise to Join Linux
Hi, Andre and I did indeed have a nice conversation on the phone. Thank you again for taking the time to talk with me and offering your assistance. As I stated on the phone, we are making a large commitment of resources to supporting Linux by releasing drivers and utilities for our products, including the FastTrak. I know we have plans to release source for our Ultra and SuperTrak series cards, but at this point I'm not sure that the way we are going to be supporting FastTrak is what you would like to see. As I said, while I cannot guarantee anything that I don't have the authority to deliver, I will pass on your requests. I will try to be an advocate for Promise in the Linux community, and an advocate for the Linux community to Promise. If the company has concerns, I will let you know what they are, and then maybe you can tell us if we are off-base with those concerns or not. I would invite anybody to contact me if you have any suggestions, any requests, whatever. As I told Andre, I won't promise something I can't personally deliver, but I will do whatever I can to help out. I'm also trying to get a technical point of contact so that you don't have to deal with a marketing weenie who doesn't understand half of what you're saying ;). Regards, Craig -Original Message- From: Andre Hedrick [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 2:43 PM To: Craig Lyons Cc: [EMAIL PROTECTED] Subject: Eye2Eye a hope for Promise to Join Linux Greetings Craig, I would like to publicly thank you for coming to the table of GNU/GPL with an open perspective. After 90 minutes on the phone, of which 45 minutes were me pointing out issues promblems and complaints w/ 20 minutes on ways to work on solutions in the near and distant future and the listening to your concerns and questions between my moments of interruption. The next conversion will not have the burst-in moments because it will be in person or my cell battery will be fully charged. Since you have stated "I will not make promise, I can not keep" this is a good thing and it will go a fair way to clean up messes from the past on both sides. I look forward to Promise working with Linux in meaningful and productive ways. Please reply and correct anything that is mistated by me or verify the correctness. This will show an action of good-faith before all those watching here. Respectfully, Andre Hedrick Linux ATA Development - 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/
obsolete code must die
Anyone concerned about the current size of the kernel source code? I am, and I propose to start cleaning house on the x86 platform. I mean it's all very well and good to keep adding features, but stuff needs to go if kernel development is to move forward. Before listing the gunk I want to get rid of, here's my justification for doing so: -- Getting rid of old code can help simplify the kernel. This means less chance of bugs. -- Simplifying the kernel means that it will be easier for newbies to understand and perhaps contribute. -- a simpler, cleaner kernel will also be of more use in an academic environment. -- a smaller kernel is easier to maintain and is easier to re-architect should the need arise. -- If someone really needs support for this junk, they will always have the option of using the 2.0.x, 2.2.x or 2.4.x series. So without further ado here're the features I want to get rid of: i386, i486 The Pentium processor has been around since 1995. Support for these older processors should go so we can focus on optimizations for the pentium and better processors. math-emu If support for i386 and i486 is going away, then so should math emulation. Every intel processor since the 486DX has an FPU unit built in. In fact shouldn't FPU support be a userspace responsibility anyway? ISA bus, MCA bus, EISA bus PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, CONFIG_ISAPNP, etc ISA, MCA, EISA device drivers If support for the buses is gone, there's no point in supporting devices for these buses. all code marked as CONFIG_OBSOLETE Since we're cleaning house we may as well get rid of this stuff. MFM/RLL/XT/ESDI hard drive support Does anyone still *have* an RLL drive that works? At the very least get rid of the old driver (eg CONFIG_BLK_DEV_HD_ONLY, CONFIG_BLK_DEV_HD_IDE, CONFIG_BLK_DEV_XD, CONFIG_BLK_DEV_PS2) parallel/serial/game ports More controversial to remove this, since they are *still* in pretty wide use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. a.out Who needs it anymore. I love ELF. I really think doing a clean up is worthwhile. Maybe while looking for stuff to clean up we'll even be able to better comment the existing code. Any other features people would like to get rid of? Any comments or suggestions? I'd love to start a good discussion about this going so please send me your 2 cents. 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: Configure.help entries for Bluetooth (updated)
>Okay, I'll bite. Ouch that hurts ;) >What's HCI stand for? >I'm guessing it ends in "Connection Interface", but the H has me stumped. Wrong guess. HCI - Host Controller Interface. People who use Bluetooth would know. HCI is the basic thing in Bluetooth world. I don't think explaining that abbreviation would help in kernel configuration. Max Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] (408) 557-1092 - 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 data corruption
On Tuesday, June 12, 2001 01:17:49 PM -0700 Larry McVoy <[EMAIL PROTECTED]> wrote: > Folks, I believe I have a reproducible test case which corrupts data in > 2.4.5. > > We do nightly, weekly, and monthly backups by copying our entire /home > partition on the company file server: > > FilesystemSize Used Avail Use% Mounted on > /dev/hda1 1.9G 1.7G 123M 93% / > /dev/hda6 1.9G 437M 1.4G 23% /tmp What flavor of IDE controller? Where is swap? -chris - 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: Configure.help entries for Bluetooth (updated)
Okay, I'll bite. What's HCI stand for? I'm guessing it ends in "Connection Interface", but the H has me stumped. Happy? Hostile? Hysterical? Hippopotamus? If we're connecting a bluetooth compliant hippopotamus to Linux, I can only hope there's an RFC somewhere explaining how to do it. That's not the kind of thing you want to make up your own interface for. Especially since Alan Cox is entirely likely to get bored enough to try and implement it some day. The pigeons didn't stop him... Rob (I can just see Alan now, sneaking up on a hippopotamus with a blue magic marker to color its teeth with, and whatever tiny PDA he's managed to port Linux to by then. A wristwatch, probably. If Telsa is in the area, the question becomes "is it possible to crash a hippopotamus?) I need to go home now. - 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/
O2 Micro CB bridge problems (was: PCMCIA troubles with an Acer TravelMate 513TE)
On Mon, Jun 11, 2001 at 10:08:39AM +0100, Paulo E. Abreu wrote: > Greetings, > > I have this laptop and I am having trouble with pcmcia in every 2.4.x > kernel. > Someone suggested that this could be a BIOS bug ... > Below there is the information, that I think is relevant to this problem. If > more is needed just tell me... You have the exact same problem as I have. Your Cardbus bridge gets memory windows allocated during initialization, but no IO port windows. This seems to be related to the resource allocation code in Linux 2.4. > Now I cannot use any PCMCIA device with this laptop, this is critical as I > cannot have any network connection... Use the drivers from the pcmcia-cs package instead of the kernel code. They don't bother with the abstract interfaces provided by the kernel and do direct pcibios_* function calls. That works where the kernel PCI hotplug code doesn't work for me. Actually I *can* make it work for me, see below for the setpci hack (replace my IO base with a free range on your computer, use the appropriate slot number in the -s argument (that was 13.0 and 13.1 in your case, for each of the PCMCIA slots)). Now back to addressing the hackers who feel addressed (and Martin Mares who I just cc'ed without remorse): I have reported my problems already once some time (a few 2.4 releases at least) back, but it didn't get fixed and pcmcia-cs worked too good so I wasn't very active in this regard. I have a Thinkpad 1200 (more specifically 1161-267), which has the same cardbus bridge Paulo has except for the revision, but see below. The problem is, in short, that the PCI code allocated memory windows for the bridge but no IO windows. The tulip chip on an inserted cb card gets then memory allocated, but the driver complains that it doesn't have IO access and stops. Using modularized drivers I can show that step by step: No drivers loaded, pristine state, no memory or I/O windows: Script started on Wed Jun 13 22:03:14 2001 [root@merv root]# lspci -vvv -s3 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 Cardbus Controller (rev 05) Subsystem: IBM: Unknown device 01a3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt+ PostWrite- 16-bit legacy interface ports at 0001 [root@merv root]# cat /proc/ioports -001f : dma1 0020-003f : pic1 0040-005f : timer 0060-006f : keyboard 0070-007f : rtc 0080-008f : dma page reg 00a0-00bf : pic2 00c0-00df : dma2 00f0-00ff : fpu 01f0-01f7 : ide0 03bc-03be : parport0 03c0-03df : vesafb 03f6-03f6 : ide0 0cf8-0cff : PCI conf1 7000-70ff : Intel Corporation 82440MX AC'97 Audio Controller 7400-743f : Intel Corporation 82440MX AC'97 Audio Controller 7800-78ff : PCI device 8086:7196 (Intel Corporation) 7c00-7c7f : PCI device 8086:7196 (Intel Corporation) 8000-801f : Intel Corporation 82440MX USB Universal Host Controller 8000-801f : usb-uhci 8040-804f : Intel Corporation 82440MX EIDE Controller 8040-8047 : ide0 Loading the drivers, memory windows get allocated: [root@merv root]# modprobe yenta_socket [root@merv root]# modprobe cb_enabler [root@merv root]# lspci -vvv -s3 00:03.0 CardBus bridge: O2 Micro, Inc. OZ6812 Cardbus Controller (rev 05) Subsystem: IBM: Unknown device 01a3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 [root@merv root]# dmesg | tail -15 Linux PCMCIA Card Services 3.1.22 options: [pci] [cardbus] [pm] PCI: Found IRQ 11 for device 00:03.0 PCI: The same IRQ used for device 00:00.1 PCI: The same IRQ used for device 00:00.2 IRQ routing conflict in pirq table for device 00:03.0 Yenta IRQ list 02b8, PCI irq10 Socket status: 3827 cs: cb_alloc(bus 1): vendor 0x1011, device 0x0019 PCI: Failed to allocate resource 0(1000-fff) for 01:00.0 got res[1080:108003ff] for resource 1 of PCI device 1011:0019 got res[1040:1043] for resource 6 of PCI device 1011:0019 PCI: Enabling device 01:00.0 ( -> 0003) Linux Tulip driver version 0.9.15-pre2 (May 16, 2001) tulip: 01:00.0: I/O region (0x0@0x1000) too small, aborting For reference, the cardbus tulip w/o IO ports: [root@merv root]# lspci -vvv -s1: 01:00.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: Abocom Systems Inc: Unknown device ab01 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- Reset- 16bInt- PostWrite+ 16-bit legacy interface ports at 0001 Load driver again, which accepts the IO window base and fixes the limit: [root@merv root]# modprobe yenta_socket [root@merv
Re: AVM A1 pcmcia, kernel 2.4.5-ac11 problem
Hello,
On Wed, 13 Jun 2001, Kai Germaschewski wrote:
> On Tue, 12 Jun 2001, Boenisch Joerg wrote:
>
> If you dig it up somewhere and get it working with 2.4.5, it would be nice
> if you let me know. We can then work together to integrate it into the
> kernel tree - I can't do it myself, because I don't have the card.
>
> --Kai
I am using the attached patch without problems with the 2.4.X series of
the linux-kernel (at the moment I am runnign 2.4.5-ac13). The patch is the
same, as the one Jochen Friedrich has sent a few day ago (including a
small fix).
Bye,
-- Andreas Klein
[EMAIL PROTECTED]
root / webmaster @cip.physik.uni-wuerzburg.de
root / webmaster @www.physik.uni-wuerzburg.de
_
| |
| Long live our gracious AMIGA! |
|___|
diff -u -r -N linux/drivers/isdn/Makefile linux-2.4.2/drivers/isdn/Makefile
--- linux/drivers/isdn/Makefile Fri Dec 29 23:40:54 2000
+++ linux-2.4.2/drivers/isdn/Makefile Sat Mar 10 15:55:59 2001
@@ -45,6 +45,15 @@
subdir-$(CONFIG_ISDN_DRV_EICON)+= eicon
subdir-$(CONFIG_HYSDN) += hysdn
+ifeq ($(CONFIG_PCMCIA),y)
+ subdir-y += pcmcia
+ subdir-m += pcmcia
+else
+ ifeq ($(CONFIG_PCMCIA),m)
+subdir-m += pcmcia
+ endif
+endif
+
obj-y += $(addsuffix /vmlinux-obj.o, $(subdir-y))
# The global Rules.make.
diff -u -r -N linux/drivers/isdn/pcmcia/Makefile
linux-2.4.2/drivers/isdn/pcmcia/Makefile
--- linux/drivers/isdn/pcmcia/Makefile Thu Jan 1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/MakefileSat Mar 10 15:55:30 2001
@@ -0,0 +1,20 @@
+#
+# Makefile for drivers/isdn/pcmcia
+#
+# Note! Dependencies are done automagically by 'make dep', which also
+# removes any old dependencies. DON'T put your own dependencies here
+# unless it's something special (ie not a .c file).
+#
+
+obj-y :=
+obj-n :=
+obj-m :=
+obj-:=
+
+ifeq ($(CONFIG_ISDN_DRV_HISAX),m)
+ ifeq ($(CONFIG_HISAX_AVM_A1_PCMCIA),y)
+obj-m += avma1_cs.o
+ endif
+endif
+
+include $(TOPDIR)/Rules.make
diff -u -r -N linux/drivers/isdn/pcmcia/avma1_cs.c
linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c
--- linux/drivers/isdn/pcmcia/avma1_cs.cThu Jan 1 01:00:00 1970
+++ linux-2.4.2/drivers/isdn/pcmcia/avma1_cs.c Sat Mar 10 15:55:30 2001
@@ -0,0 +1,541 @@
+/*==
+
+A PCMCIA client driver for AVM B1/M1/M2
+
+Written by Carsten Paeth, [EMAIL PROTECTED]
+
+==*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+int avm_a1_init_pcmcia(void *pcm_iob, int pcm_irq, int *busy_flag, int prot);
+void HiSax_closecard(int cardnr);
+
+
+/*
+ All the PCMCIA modules use PCMCIA_DEBUG to control debugging. If
+ you do not define PCMCIA_DEBUG at all, all the debug code will be
+ left out. If you compile with PCMCIA_DEBUG=0, the debug code will
+ be present but disabled -- but it can then be enabled for specific
+ modules at load time with a 'pc_debug=#' option to insmod.
+*/
+#ifdef PCMCIA_DEBUG
+static int pc_debug = PCMCIA_DEBUG;
+MODULE_PARM(pc_debug, "i");
+#define DEBUG(n, args...) if (pc_debug>(n)) printk(KERN_DEBUG args);
+static char *version =
+"avma1_cs.c 1.00 1998/01/23 10:00:00 (Carsten Paeth)";
+#else
+#define DEBUG(n, args...)
+#endif
+
+/**/
+
+/* Parameters that can be set with 'insmod' */
+
+static int default_irq_list[11] = { 15, 13, 12, 11, 10, 9, 7, 5, 4, 3, -1 };
+static int irq_list[11] = { -1 };
+static int isdnprot = 2;
+
+MODULE_PARM(irq_list, "1-11i");
+MODULE_PARM(isdnprot, "1-4i");
+
+/**/
+
+/*
+ The event() function is this driver's Card Services event handler.
+ It will be called by Card Services when an appropriate card status
+ event is received. The config() and release() entry points are
+ used to configure or release a socket, in response to card insertion
+ and ejection events. They are invoked from the skeleton event
+ handler.
+*/
+
+static void avma1cs_config(dev_link_t *link);
+static void avma1cs_release(u_long arg);
+static int avma1cs_event(event_t event, int priority,
+ event_callback_args_t *args);
+
+/*
+ The attach() and detach() entry points are used to create and destroy
+ "instances" of the driver, where each instance represents everything
+ needed to manage one actual PCMCIA card.
+*/
+
+static dev_link_t *avma1cs_attach(void);
+static void avma1cs_detach(dev_link_t *);
+
+/*
+ The dev_info variable is the "key" that is used to match up
accounting for threads
Hi. First, sorry if this is a glibc issue. Just chose to ask here first. I want to know the CPU time used by a POSIX-threaded program. I have tried to use getrusage() with RUSAGE_SELF and RUSAGE_CHILDREN. Problem: main thread just do nothing, spawns children and waits. And I get always 0 ru_utime. I guess it can be because of 2 things: - RUSAGE_CHILDREN only works for fork()'ed children (although in linux threads and processes are the same). Perhaps fork() sets some kind of flag in clone() for accounting. - AFAIK, linux puts an intermediate 'thread controller'. That controller uses no CPU time, and RUSAGE_CHILDREN gets only the first children level. Any suggestion to mesaure threads CPU time ? I can't manage only with wall-time, because I'm not sure to have all the box just for me. And I would like also to mesaure system time to evaluate contention. TIA -- J.A. Magallon # Let the source be with you... mailto:[EMAIL PROTECTED] Linux Mandrake release 8.1 (Cooker) for i586 Linux werewolf 2.4.5-ac13 #1 SMP Sun Jun 10 21:42:28 CEST 2001 i686 - 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: Changing CPU Speed while running Linux
Arjan van de Ven wrote: > > Sven Geggus wrote: > > > > Hi there, > > > > on my Elan410 based System it is very easy to change the CPU clock > > speed by means od two outb commands. > > > > I was wondering, if it does some harm to the Kernel if the CPU is > > reprogrammed using a different CPU clock speed, while the system is up and > > running. > > I have a module for the K6 PowerNow which allows you to do > > echo 450 > /proc/sys/cpu/0/frequency > > and does the right thing wrt udelay / bogomips etc.. > I can dig it out if you want.. sounds like this should be a more generic > thing. Yes, please. After (all) Athlon 4/MT (Palomino) and Duron mobile feature PowerNow! it should be usefull for more and more people. Regards, Dieter BTW I think there are only a "few" K6-2+/K6-III+ out ;-) But PowerNow! is nice stuff. I had an eye on an 1 GHz Palomino at CeBIT '2001. -- Dieter Nützel Graduate Student, Computer Science University of Hamburg Department of Computer Science Cognitive Systems Group Vogt-Kölln-Straße 30 D-22527 Hamburg, Germany email: [EMAIL PROTECTED] @home: [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/
Eye2Eye a hope for Promise to Join Linux
Greetings Craig, I would like to publicly thank you for coming to the table of GNU/GPL with an open perspective. After 90 minutes on the phone, of which 45 minutes were me pointing out issues promblems and complaints w/ 20 minutes on ways to work on solutions in the near and distant future and the listening to your concerns and questions between my moments of interruption. The next conversion will not have the burst-in moments because it will be in person or my cell battery will be fully charged. Since you have stated "I will not make promise, I can not keep" this is a good thing and it will go a fair way to clean up messes from the past on both sides. I look forward to Promise working with Linux in meaningful and productive ways. Please reply and correct anything that is mistated by me or verify the correctness. This will show an action of good-faith before all those watching here. Respectfully, Andre Hedrick Linux ATA Development - 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] do proper cleanups before requesting irq
Pavel Machek wrote:
> > The problem is that there are comparisons of pointers to task_struct when
> > deciding if the task is alive. If one task dies and other one starts, it is
> > possible (is it?) that the task structure of the newly created task resides
> > at the very address where was the dead one's, so comparing pointers is not
> > reliable. This patch changes it to comparisons of task's pids.
> > Can anyone, please, atleast tell me if this patch is correct?
> it might be better but it is not correct. pids are reused, too
Many thanks for reply.
If everything can be reused then it seems that the correct approach is to do a
cleanup when the task terminates, not when other one tries to request an irq.
The following patch does exactly this.
Please, once again, is this correct now?
--
--- linux/arch/i386/kernel/irq.hFri May 12 21:38:59 2000
+++ linux/arch/i386/kernel/irq.hWed Jun 13 18:44:06 2001
@@ -85,6 +85,7 @@
extern void init_IRQ_SMP(void);
extern int handle_IRQ_event(unsigned int, struct pt_regs *, struct irqaction *);
extern int setup_x86_irq(unsigned int, struct irqaction *);
+extern void release_x86_irqs(struct task_struct *);
/*
* Various low-level irq details needed by irq.c, process.c,
--- linux/arch/i386/kernel/process.cMon Dec 11 17:29:12 2000
+++ linux/arch/i386/kernel/process.cWed Jun 13 18:58:00 2001
@@ -544,6 +544,7 @@
void release_thread(struct task_struct *dead_task)
{
+release_x86_irqs(dead_task);
}
/*
--- linux/arch/i386/kernel/vm86.c Sat May 5 06:31:51 2001
+++ linux/arch/i386/kernel/vm86.c Wed Jun 13 19:01:26 2001
@@ -618,6 +618,14 @@
}
read_unlock(_lock);
return ret;
+}
+
+void release_x86_irqs(struct task_struct *task)
+{
+ int i;
+ for (i=3; i<16; i++)
+ if (vm86_irqs[i].tsk == task)
+ free_vm86_irq(i);
}
static inline void handle_irq_zombies(void)
-
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: AVM A1 pcmcia, kernel 2.4.5-ac11 problem
On Tue, 12 Jun 2001, Boenisch Joerg wrote: > I hope not to be off topic! (In that case could you tell me where to ask?) You can try [EMAIL PROTECTED] or the newsgroup de.alt.comm.isdn4linux.de, but I can't guarantee success there, either. > Kernel of course is compiled with ISDN support and low-level AVM-A1-PCMCIA. > After installation in /lib/modules hisax.o can be found, but not avma1_cs.o > cardmgr[1070]: module /lib/modules/2.4.5-ac11/pcmcia/avma1_cs.o not > available The problem is obviously that you're lacking the avma1_cs.o module. I believe it was distributed separately and not included in the kernel tree / pcmcia-cs. If you want to go look for it, try linux-pcmcia on sourceforge.net, or your favorite web search engine. If you dig it up somewhere and get it working with 2.4.5, it would be nice if you let me know. We can then work together to integrate it into the kernel tree - I can't do it myself, because I don't have the card. --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/
RE: bzDisk compression Q; boot debug Q
> Question 2, apparently ramdisk uses gzip compression; the name of the > kernel from make bzImage seems to maybe refer to bzip2 compression. Is > the kernel image using gzip or bzip2 compression for bzImage? Would bzImage stands for "big zImage" - this is a format invented for kernels that don't fit into zImage. bzip2 has nothing to do with it :) - 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.2.19: eepro100 and cmd_wait issues
I would suggest that you use the e100 driver instead of the eepro100 driver. We switched to the e100 driver from the eepro100 driver, and a number of our FTP, NFS and rsync (IE: High bandwidth apps) problems went away. Our system are mostly 6 Proc boxes with 4 gigs of memeory. -- Jason Murphy _ Get your FREE download of MSN Explorer at http://explorer.msn.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: sis630 - help needed debugging in the kernel
Thanks for the quick reply! On Wed, 13 Jun 2001 09:54:21 -0700 (PDT) James Simmons <[EMAIL PROTECTED]> wrote: > > > I currently try to debug why the sisfb driver crashes my machine. (SIS 630 > > based laptop - linux-2.4.5-ac13). > > You can do one of two things. Post both System.map and the complete oops > or you can run ksymoops on the oops. I can find the problem then. Thanks. ksymoops' output is attached. [...] k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. ksymoops.txt
bzDisk compression Q; boot debug Q
First I have a question about the compression of bzDisk. While trying to debug the reason for a modular boot failure versus a successful non-module boot (XFS filesystem for root), I found that I can mount my initial ramdisk on loopback as a means of examining which modules are available to it. However, it doesn't actually point out which modules were loaded at the time when a filesystem mount fails. Viewing ramdisk is via: gzip -dc your.img > somefile mount -o loop somefile somedir Question 1, how hard would it be to cause failure of mount of root filesystem to also output a list of current modules it has loaded? Question 2, apparently ramdisk uses gzip compression; the name of the kernel from make bzImage seems to maybe refer to bzip2 compression. Is the kernel image using gzip or bzip2 compression for bzImage? Would anything be gained in reducing boot size requirements by running bzip2 compression for any initial ramdisk, versus gzip compression? D. Stimits, [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/
Re: SMP module compilation on UP?
Mark Mokryn wrote: > > Hi, > > Is it possible to build an SMP module on a machine running a UP kernel > (or vice versa)? We of course get unresolved symbols during module load > due to the smp prefix on the ksyms, and haven't seen how to get around > it. (Defining __SMP__ does not cut it, though I believe this used to > work a while ago). > Why not just run an SMP kernel on UP machine? Yes, there may be minor performance penalty but that may be irrelevant for you if it lets you build and load SMP modules on that machine. With a UP kernel running, you will be able to build SMP modules but not load them. -- Khalid Khalid Aziz Linux Development Laboratory (970)898-9214Hewlett-Packard [EMAIL PROTECTED]Fort Collins, CO - 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: Undocumented configuration symbols in 2.4.6pre2
Randy, >Could you make these 5 instances of "Not unsure" be more palatable and less confusing >? Oops, blind cut without reading carefully :). Thanks Max Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] (408) 557-1092 - 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/
Configure.help entries for Bluetooth (updated)
CONFIG_BLUEZ Bluetooth is low-cost, low-power, short-range wireless technology. It was designed as a replacement for cables and other short-range technologies like IrDA. Bluetooth operates in personal area range that typically extends up to 10 meters. More information about Bluetooth can be found at http://www.bluetooth.com Linux Bluetooth subsystem consist of several layers: HCI Core (device and connection manager, scheduler) HCI Device drivers (interface to the hardware) L2CAP Module (L2CAP protocol) Say Y here to enable Linux Bluetooth support and to build HCI Core layer. To use Linux Bluetooth subsystem, you will need several user-space utilities like hciconfig and hcid. These utilities and updates to Bluetooth kernel modules are provided in the BlueZ package. For more information, see http://bluez.sf.net. If you want to compile HCI Core as module (hci.o) say M here. Not sure ? say N. CONFIG_BLUEZ_L2CAP L2CAP (Logical Link Control and Adaptation Protocol) provides connection oriented and connection-less data transport. L2CAP support is required for most Bluetooth applications. Say Y here to compile L2CAP support into the kernel or say M to compile it as module (l2cap.o). Not sure ? say M. CONFIG_BLUEZ_HCIUART Bluetooth HCI UART driver. This driver is required if you want to use Bluetooth devices with serial port interface. Say Y here to compile support for Bluetooth UART devices into the kernel or say M to compile it as module (hci_uart.o). Not sure ? say M. CONFIG_BLUEZ_HCIUSB Bluetooth HCI USB driver. This driver is required if you want to use Bluetooth devices with USB interface. Say Y here to compile support for Bluetooth USB devices into the kernel or say M to compile it as module (hci_usb.o). Not sure ? say M. CONFIG_BLUEZ_HCIEMU Bluetooth Virtual HCI device driver. This driver is required if you want to use HCI Emulation software. Say Y here to compile support for Virtual HCI devices into the kernel or say M to compile it as module (hci_usb.o). Not sure ? say M. Thanks Max Maksim Krasnyanskiy Senior Kernel Engineer Qualcomm Incorporated [EMAIL PROTECTED] (408) 557-1092 - 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: ethtool MII helpers
Donald Becker wrote: > I was on vacation, and thus didn't have the opportunity to comment earlier. Thanks a bunch for your comments here. > On Tue, 12 Jun 2001, Jeff Garzik wrote: > > > > - You are proposing some caching for the MII registers. I suppose that you > > > would like to have this code also working with whatever caching will be > > > done for MII access that was recently discussed. Wouldn't this produce > > > double caching under some circumstances ? > > > > You misunderstood the code. The "caching" here is whatever is -already- > > being done by the driver. Many Becker-style drivers cache the > > advertising value. If such a driver uses the ethtool MII code, that is > > one less MII read that needs to occur. > > That's not the way I read the code. It appears to cache various MII > management registers. I still think there is a misunderstanding here, brought about my short explanation and lack of docs.. The key here is the lifetime of the cache. Without extra work on the part of the driver author, the data in struct ethtool_mii_info only exists for a single ioctl call. ethtool_mii_info is a container, not a data cache. So, if you already have MII register cached somewhere, like advertising, or you perform MII reads before calling ethtool_mii_[gs]set, then those values are "cached" in the sense that mii.c will not re-read the register values. Since MII reads are not the quickest operations in the world, I preferred to be flexible in allowing what will occur before and after the ethtool_mii_[gs]set call. > Caching almost any MII register, except the ID registers, may be > invalid. Agreed. I even said this in an MII thread on lkml a couple weeks ago ;-) > Caching and ioctl() rate-limiting are both a problem for a program I use > frequently. It monitors the transceiver to report the timing and state > transitions of autonegotiation. It internally handles polling rate > limiting by backing off the poll rate when nothing is happening. But > when something happens, it polls every timer tick for the next 30 > ticks. Unfortunately that is at loggerheads with the potential for a bunch of people to soak the system with unpriveleged MII reads via ioctl. That is the core problem, and caching or rate-limiting is only a suggested solution. I could forget about rate-limiting if we required CAP_NET_ADMIN and/or CAP_RAW_IO for all these ioctls, but that might cause complaints too.. > > David's argument is for ethtool, which originally comes out of the sparc > > port (see include/asm-sparc/ethtool.h in older trees), and has been > > around for a while, but doesn't enjoy the massive deployment that the > > MII ioctls enjoy. We have control over the ethtool API, and we can > > correct its deficiencies, whereas any MII spec deficiencies must be > > worked out inside the driver. > > You should first understand what MII management registers provide before > deciding that you can do better. There are some design uglinesses, > but it was put together by people that lived and breathed transceivers. > It has been proven over six or seven years or use with no incompatible > changes to the original software interface definition. > > >... > > Further, for the userland ethtool program, support for MII ioctls will > > be added soon, so that there will be no need for additional mii-tool or > > mii-diag tools. > > This could be easily reversed: the additional ethtool program was not > needed in the first place. > > > > This is nice, but I would like to able to restart autonegotiation even > > > without changing any of the advertised capabilities. If I missed this > > > possibility, please point me to it... > > > > no, that is a capability which needs to be added to ethtool. > > ETHTOOL_RENEG or ETHTOOL_ANRESTART or something. Basically kick the > > link state machine, whether such a state machine is in the driver or in > > the MII phy. That's the one big thing that mii-tool can do that ethtool > > cannot, AFAICS. > > An additional capability of the MII ioctl() is that it permits sending > "next page" extended information to the link partner. [move this down here] > This message covers >Why caching MII values doesn't work. [responded above] >Why extended MII values are useful. Ok, thanks, agreed. About the larger issue of why ethtool exists, I wonder about things like: how do the MII ioctls cover things like switching transceivers? supporting aui/10b2? supporting sym phys? ethtool is not just about 10/100 media. It's a general software diagnostics utility and tuning tool for your ethernet driver. The same kernel interface and the same userland program will allow me to associate an ethernet interface with a driver and bus location, adjust media settings, adjust interrupt mitigation settings, or perhaps even perform a driver-specific duty. I am very much convinced that the extended MII ioctls are useful, and would even support codifying them in sockios.h, using the SIOCMII*
Re: 2.4.6-pre2, pre3 VM Behavior
On Wed, 13 Jun 2001, Tom Sightler wrote: > 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet, > close to wire speed). At this point Linux has yet to write the first byte to > disk. OK, this might be an exaggerated, but very little disk activity has > occured on my laptop. > > 2. Suddenly it's as if Linux says, "Damn, I've got a lot of data to flush, > maybe I should do that" then the hard drive light comes on solid for several > seconds. During this time the ftp transfer drops to about 1/5 of the original > speed. > > 3. After the initial burst of data is written things seem much more reasonable, > and data streams to the disk almost continually while the rest of the transfer > completes at near full speed again. > > Basically, it seems the kernel buffers all of the incoming file up to nearly > available memory before it begins to panic and starts flushing the file to disk. > It seems it should start to lazy write somewhat ealier. > Perhaps some of this is tuneable from userland and I just don't > know how. Actually, it already does the lazy write earlier. The page reclaim code scans up to 1/4th of the inactive_dirty pages on the first loop, where it does NOT write things to disk. On the second loop, we start asynchronous writeout of data to disk and and scan up to 1/2 of the inactive_dirty pages, trying to find clean pages to free. Only when there simply are no clean pages we resort to synchronous IO and the system will wait for pages to be cleaned. After the initial burst, the system should stabilise, starting the writeout of pages before we run low on memory. How to handle the initial burst is something I haven't figured out yet ... ;) > Anyway, things are still much better, with older kernels things > would almost seem locked up during those 10-15 seconds but now > my apps stay fairly responsive (I can still type in AbiWord, > browse in Mozilla, etc). This is due to this smarter handling of the flushing of dirty pages and due to a more subtle bug where the system ended up doing synchronous IO on too many pages, whereas now it only does synchronous IO on _1_ page per scan ;) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ - 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] 2.4.6-pre2 page_launder() improvements
On Wed, 13 Jun 2001, Alok K. Dhir wrote: > > Are these page_launder improvements included in 2.4.6-pre3? Linus > mentions "VM tuning has also happened" in the announcement - but there > doesn't seem to be mention of it in his list of changes from -pre2... Yes, it 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: Undocumented configuration symbols in 2.4.6pre2
Hi, Could you make these 5 instances of "Not unsure" be more palatable and less confusing? E.g., "Not sure" or "If not sure". But not the double negative... As is, it basically says: "Sure ? say M." ~Randy > -Original Message- > From: Maksim Krasnyanskiy [mailto:[EMAIL PROTECTED]] > > >CONFIG_BLUEZ > >CONFIG_BLUEZ_HCIEMU > >CONFIG_BLUEZ_HCIUART > >CONFIG_BLUEZ_HCIUSB > >CONFIG_BLUEZ_L2CAP > > Here we go: > > CONFIG_BLUEZ ... > >Say Y here to enable Linux Bluetooth support and to build HCI Core >layer. > ... > >Not unsure ? say N. > > CONFIG_BLUEZ_L2CAP ... > >Say Y here to compile L2CAP support into the kernel or say > M to compile it >as module (l2cap.o). > >Not unsure ? say M. > > CONFIG_BLUEZ_HCIUART ... > >Say Y here to compile support for Bluetooth UART devices > into the kernel >or say M to compile it as module (hci_uart.o). > >Not unsure ? say M. > > > CONFIG_BLUEZ_HCIUSB ... > >Say Y here to compile support for Bluetooth USB devices > into the kernel >or say M to compile it as module (hci_usb.o). > >Not unsure ? say M. > > CONFIG_BLUEZ_HCIEMU ... > >Not unsure ? say M. - 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: Has it been done: User Script File System?
Quoting Russ Lewis <[EMAIL PROTECTED]>: > mount -t userfs /etc/myfs.conf /myfs I did this a while ago: I wrote userfs which allowed arbirary filesystems to be implemented in user space. One of these was a filesystem which allowed you to embed scripts in symlinks, such that stdout of the script was read as the contents of the file. userfs has fallen into disrepair lately, but there are other projects with similar goals. See http://www.goop.org/~jeremy/userfs/. 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/
VEXUS VAR-Business Dealer UpDate Prices List
MEMORY Spectek or Micron lifetime warranty (Min.Qty. Less 100) $ 8.95 32 MB 168pins PC-100 $ 12.75 64 MB 168pins PC-100/PC-133 $ 21.50 128 MB 168pins PC-100/PC-133 $ 41.50 256 MB 168pins PC-100/PC-133 Hard Drive (Min.Qty. Less 50) $ 63.50 Hard Drive 10GB 4500rpm ATA100 Quantum $ 69.00 Hard Drive 10GB 5400rpm ATA100 Western Digital $ 72.00 Hard Drive 20GB 5400rpm ATA100 Fujitsu $ 89.50 Hard Drive 20GB 7200rpm ATA100 Quantum $87.00 Hard Drive 30GB 5400rpm ATA100 Seagate $110.00 Hard Drive 30GB 7200rpm ATA100 Seagate $97.00 Hard Drive 40GB 5400rpm ATA100 Western Digital $128.00 Hard Drive 40GB 7200rpm ATA100 Quantum Mother Board (Min.Qty. Less 40) $58.50 MB PC-Chips 755LMR AT w/V, S, 10/100, 56K $60.50 MB PC-Chips 756LMRT ATX w/V, S, 10/100, 56K $60.00 MB PC-Chips 757LMRT ATX w/V, S, 10/100, 56K $62.75 MB PC-Chips 598LMR AT w/V, S, 10/100, 56K $64.50 MB PC-Chips 810LMR ATX w/V, S, 10/100, 56K $126.50 MB Intel D815EEA2L ATX FC-PGA PC133 w/S, V, 10/100 $125.00 MB Intel D815EEAA ATX FC-PGA PC133 w/S, V $135.00 MB Intel D815EEAAL ATX FC-PGA PC133 w/S, V, 10/100 $117.00 MB Intel D815EPEA2 ATX FC-PGA PC133 w/Sound & Video $107.50 MB Intel CA810E ATX FC-PGA PC133 w/Sound $118.00 MB ASUS CUSL2-C ATX Plain FC-PGA $108.50 MB ASUS CU V4X-E ATX Plain FC-PGA $115.00 MB ASUS CU V4X-E ATX FC-PGA w/sound $87.00 MB ASUS CUSIMMR ATX w/video, audio, lan Processors INTEL (Min.Qty. Less 20) $ 69.50 Intel Celeron 700Mhz FC-PGA BOX $ 86.00 Intel Celeron 766Mhz FC-PGA BOX $ 115.00Pentium III-733EB FC-PGA, 256KB, 133Mhz BOX $ 119.00Pentium III-750EFC-PGA, 256KB, 100Mhz BOX $ 162.00Pentium III-850E FC-PGA, 256KB, 100Mhz BOX $ 172.00Pentium III-866EB FC-PGA, 256KB, 133Mhz BOX $ 168.00Pentium III-866EB FC-PGA, 256KB, 133Mhz OEM $ 189.00Pentium III-933EB FC-PGA, 256KB, 133Mhz BOX $ 182.00Pentium III-933EB FC-PGA, 256KB, 133Mhz OEM $ 217.00Pentium III-1000EB FC-PGA, 256KB, 133Mhz BOX $ 199.00Pentium III-1000EB FC-PGA, 256KB, 133Mhz OEM $ 275.00Pentium 4-1.3GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) $ 295.00Pentium 4-1.4GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) $ 363.00Pentium 4-1.5GB FC-PGA, 256KB, 133Mhz BOX (min 5 pcs) Processors AMD (Min.Qty. Less 20) $40.75 AMD K6II 500 Mhz OEM $39.75 AMD Duron 700Mhz OEM $41.75 AMD Duron 750Mhz OEM $54.50 AMD Duron 800Mhz OEM $89.50 AMD K7 T-Bird 850Mhz 256KB OEM $103.75 AMD K7 T-Bird 900Mhz 256KB OEM $134.50 AMD K7 T-Bird 1GB 256KB OEM $146.00 AMD K7 T-Bird 1.1GB 256KB OEM $155.00 AMD K7 T-Bird 1.2GB 256KB OEM $156.50 AMD K7 T-Bird 1.2GB 256KB PC266 OEM $175.00 AMD K7 T-Bird 1.3GB 256KB OEM $217.00 AMD K7 T-Bird 1.3GB 256KB PC266 OEM Video Card (min 80 pcs) $ 20.50 VGA Card AGP 8 MB SIS $ 21.50 VGA Card AGP 8 MB S3 $ 36.50 VGA Card AGP 16 MB ATI $ 39.50 VGA Card AGP 32 MB ATI $149.00 VGA Card AGP 32 MB ATI All in Wonder OEM (min 10pcs) I/O Cards $ 24.00 ATIO Card PCI (2 Serial, 1 Paralel, 1 Game) $ 13.50 2-USB Card PCI $ 23.00 4-USB Card PCI Sound Card (min 80 pcs) $ 7.99 Sound Card ISA $ 7.99 Sound Card PCI Printers (min 20 pcs) $ 37.00 APOLLO P-1200 or P2100-201U 3.5/1.5ppm black/color $ 45.00 APOLLO P-2200 6/3ppm black/color $ 44.75 CANON BJC-1000 Color printer 6/4ppm black/color $ 48.75 CANON BJC-2110 Color printer 5/2ppm black/color $ 88.75 CANON BJC-3000 Color Printer 6/4ppm black/Color $ 93.75 HP DeskJet 840C 8/5ppm black/color $283.00 HP DeskJet 970C 12/10ppm black/color (min 10pcs) Scanner (min 10 pcs) $46.50 Optic Pro P12 36Bit 1200x600 DPI $64.75 AFGA E20 36Bit USB 600X1200 DPI $59.00 HP Scanjet 4200cse $93.00 HP Scanjet 3400cxi Monitors (min 20 pcs) $ 95.50 Monitor 14.28 AOC $112.00 Monitor 15 .28 Generic $115.00 Monitor 15 .28 KDS, AOC, Proview or KDS $137.00 Monitor 17 .28 Hyundai $147.00 Monitor 17 .28 KDS, AOC, Proview Accessories (min 80pcs) $ 3.75 Keyboard AT or PS2 $ 1.69 Mouse Serial or PS2 2-Bottons $ 2.80 Mouse Serial or PS2 w/scroll $ 2.25 Headset $ 3.25 Speaker 180W $24.00 Speaker Flat Benwin Notice: We only send this message to Computer manufacturers/dealers, Resellers, VARs, Computer consultants, Computer repair companies, Software developers, Educational institutions, Government agencies, Corporate and Retail businesses that have
Re: net_device list in kernel
Em Wed, Jun 13, 2001 at 12:14:18PM -0700, [EMAIL PROTECTED] escreveu:
>
> Hi,
>
> I have one doubt.
>
> There is a list of the devices(net_device{} structures) maintained in kernel which
>has all the interfaces initialised by that time. This list is refrenced by dev_base
>variable.
>
> I need following info
>
> 1) does kernel maintain a global variable which keeps the count of net_device{} in
>above list?
not that I'm aware
> 2) Is this list modified(net_device{} added or deleted ) once it's initialised at
>boot time?
Yes, think about loading a module for a network card, it will add one entry
(or more in some cases) to this list, or think about net aliases. Look at
register_netdevice in net/core/dev.c
- Arnaldo
-
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/
2.4.6-pre2, pre3 VM Behavior
Hi All, I have been using the 2.4.x kernels since the 2.4.0-test days on my Dell 5000e laptop with 320MB of RAM and have experienced first hand many of the problems other users have reported with the VM system in 2.4. Most of these problems have been only minor anoyances and I have continued testing kernels as the 2.4 series has continued, mostly without noticing much change. With 2.4.6-pre2, and -pre3 I can say that I have seen a marked improvement on my machine, especially in interactive response, for my day to day workstation uses. However, I do have one observation that seems rather strange, or at least wrong. I, on occasion, have the need to transfer relatively large files (750MB-1GB) from our larger Linux servers to my machine. I usually use ftp to transfer these files and this is where I notice the following: 1. Transfer of the first 100-150MB is very fast (9.8MB/sec via 100Mb Ethernet, close to wire speed). At this point Linux has yet to write the first byte to disk. OK, this might be an exaggerated, but very little disk activity has occured on my laptop. 2. Suddenly it's as if Linux says, "Damn, I've got a lot of data to flush, maybe I should do that" then the hard drive light comes on solid for several seconds. During this time the ftp transfer drops to about 1/5 of the original speed. 3. After the initial burst of data is written things seem much more reasonable, and data streams to the disk almost continually while the rest of the transfer completes at near full speed again. Basically, it seems the kernel buffers all of the incoming file up to nearly available memory before it begins to panic and starts flushing the file to disk. It seems it should start to lazy write somewhat ealier. Perhaps some of this is tuneable from userland and I just don't know how. This was much less noticeable on a server with a much faster SCSI hard disk subsystem as it took significantly less time to flush the information to the disk once it finally starterd, but laptop hard drives are traditionally poor performers and at 15MB/s it take 10-15 seconds before things stable out, just from transferring a file. Anyway, things are still much better, with older kernels things would almost seem locked up during those 10-15 seconds but now my apps stay fairly responsive (I can still type in AbiWord, browse in Mozilla, etc). Later, 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/
Looking for ifenslave.c
Hello, The Ethernet bonding module is useless without ifenslave.c. I'm making a Debian package for it, and I have tried to find the "offical" distribution of this small program. I could not find an authorative source, instead a lot of copies and patched versions are scattered around the Internet (I maintain a patched version myself too). I would like to combine all the useful extra features and patches into this Debian package, so if you know of a patched version or maintain one yourself, please send it to me. Thanks, -- Met vriendelijke groet / with kind regards, Guus Sliepen <[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/
net_device list in kernel
Hi,
I have one doubt.
There is a list of the devices(net_device{} structures) maintained in kernel which
has all the interfaces initialised by that time. This list is refrenced by dev_base
variable.
I need following info
1) does kernel maintain a global variable which keeps the count of net_device{} in
above list?
2) Is this list modified(net_device{} added or deleted ) once it's initialised at boot
time?
PLEASE reply to my PERSONAL account. I haven't subscribed to this mailing list.
thanks & regards,
Deepika
__
123India.com - India's Premier Portal
Get your Free Email Account at http://www.123india.com
--- End of forwarded message ---
__
123India.com - India's Premier Portal
Get your Free Email Account at http://www.123india.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.6-pre3
On Tuesday, 12 June 2001, at 18:42:45 -0700, Linus Torvalds wrote: > > User-noticeable things: if you are tired of not being able to NFS-export > your reiserfs tree, this should make you happy. > > VM tuning has also happened, with Rik van Riel, Mike Galbraith, Marcelo > Tosatti and Andrew Morton all doing various tweaks. Give it a whirl. > Here is my rather simple VM stressing test. Just opening some applications on the machine I use every day. Tested with 2.4.4 and 2.4.6-pre3. Machine OFF. Power ON. Some processes running in the background, but iddle (process list available on request, should it matters). Each section shows output from "free" with additional applicatons started. Once KDE, Mozilla, Konqueror and StarOffice are loaded, they are closed in the reverse order as the were started. -- Linux joseluis 2.4.4 #1 lun abr 30 12:02:46 CEST 2001 i686 unknown -- Just booted --- total used free sharedbuffers cached Mem:127124 30788 96336 0 3392 12360 -/+ buffers/cache: 15036 112088 Swap: 128516 0 128516 + KDE 2.1.1 + rxvt -- total used free sharedbuffers cached Mem:127124 85276 41848 0 5924 39656 -/+ buffers/cache: 39696 87428 Swap: 128516 0 128516 + Konqueror (about:) + Mozilla 0.9.1 (www.engardelinux.com) --- total used free sharedbuffers cached Mem:127124 125620 1504 0524 45896 -/+ buffers/cache: 79200 47924 Swap: 128516 49072 79444 + StarOffice 5.2 (ThreeDimensions.sdd) -- total used free sharedbuffers cached Mem:127124 125656 1468 0592 71964 -/+ buffers/cache: 53100 74024 Swap: 128516 104084 24432 + Konqueror (about:) + Mozilla 0.9.1 (www.engardelinux.com) --- total used free sharedbuffers cached Mem:127124 102812 24312 0780 73900 -/+ buffers/cache: 28132 98992 Swap: 128516 102272 26244 KDE 2.1.1 + rxvt total used free sharedbuffers cached Mem:127124 114660 12464 0 1176 98232 -/+ buffers/cache: 15252 111872 Swap: 128516 51068 77448 Back to the start - total used free sharedbuffers cached Mem:127124 124100 3024 0 2692 110980 -/+ buffers/cache: 10428 116696 Swap: 128516 47972 80544 swapoff -a -- 7 seconds, machine responsive total used free sharedbuffers cached Mem:127124 91152 35972 0 2888 68640 -/+ buffers/cache: 19624 107500 Swap:0 0 0 --- Linux joseluis 2.4.6-pre3 #1 mié jun 13 11:22:51 CEST 2001 i686 unknown --- Just booted --- total used free sharedbuffers cached Mem:127120 32108 95012 0 1468 14908 -/+ buffers/cache: 15732 111388 Swap: 128516 0 128516 KDE 2.1.1 + rxvt total used free sharedbuffers cached Mem:127120 85316 41804 0 3036 42464 -/+ buffers/cache: 39816 87304 Swap: 128516 0 128516 + Konqueror (about:) + Mozilla 0.9.1 (www.engardelinux.com) --- total used free sharedbuffers cached Mem:127120 124804 2316 0356 69264 -/+ buffers/cache: 55184 71936 Swap: 128516 59236 69280 + StarOffice 5.2 (ThreeDimensions.sdd) -- total used free sharedbuffers cached Mem:127120 124308 2812 0 1408 88592 -/+ buffers/cache: 34308 92812 Swap: 128516 109104 19412 + Konqueror (about:) + Mozilla 0.9.1 (www.engardelinux.com) --- total used free sharedbuffers cached Mem:127120 104168 22952
Re: threading question
>I got that response too. When I pressed kernel people for details it turns >out that they think having hundreds of runnable threads/processes (mostly >the same thing under Linux) is wasteful. The scheduler is just not optimised >for that. Try out the http://lse.sourceforge.net/scheduling patches. The MQ kernel scheduler sure can handle this kind of load :-) Hubertus Franke Enterprise Linux Group (Mgr), Linux Technology Center (Member Scalability) , OS-PIC (Chair) email: [EMAIL PROTECTED] (w) 914-945-2003(fax) 914-945-4425 TL: 862-2003 bert hubert <[EMAIL PROTECTED]>@vger.kernel.org on 06/13/2001 01:31:39 PM Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: threading question On Tue, Jun 12, 2001 at 12:06:40PM -0700, Kip Macy wrote: > This may sound like flamebait, but its not. Linux threads are basically > just processes that share the same address space. Their performance is > measurably worse than it is on most commercial Unixes and FreeBSD. Thread creation may be a bit slow. But the kludges to provide posix threads completely from userspace also hurt. Notably, they do not scale over multiple CPUs. > They are not, or at least two years ago, were not POSIX compliant > (they behaved badly with respect to signals). The impoverished POSIX threads are silly with respect to signals. I do almost all my programming these days with pthreads and I find that I really do not miss signals at all. > from Larry McVoy's home page attributed to Alan Cox illustrates this > reasonably well: "A computer is a state machine. Threads are for people > who can't program state machines." Sorry for not being more helpful. I got that response too. When I pressed kernel people for details it turns out that they think having hundreds of runnable threads/processes (mostly the same thing under Linux) is wasteful. The scheduler is just not optimised for that. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] 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: Has it been done: User Script File System?
[EMAIL PROTECTED] (Russ Lewis) writes: > Is there any filesystem in Linux that uses user scripts/executables to > implement the various function calls? What I'm thinking of is something It has been done before. http://www.ibiblio.org/pub/Linux/ALPHA/userfs/userfs.lsm describes a patch/kernel module for kernel 1.2.10, 1.3.13 and 2.0.30. I vaguely remember that some more resen suggestion was to implement it with the some usper-space nfs-deamon. -- hash-bang-slash-bin-slash-bash - 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/
2.4.4 Oops in ext2 and strange /proc/ksyms
Hi folks! After seeing the Oops below (and rebooting), I looked into /proc/ksyms (because ksymoops complained about mismatches), and I could not find system_call, do_page_fault, etc. Shouldn't they be there? When doing ksymoops with /proc/ksyms I found recursive calling of do_brk, which for sure is not the right thing. The machine is a dual PII-450, kernel is 2.4.4 vanilla with Neil Brown's knfsd-patch. -- ksymoops 2.4.0 on i686 2.4.4. Options used -V (default) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.4/ (default) -m /usr/src/linux/System.map (specified) No modules in ksyms, skipping objects No ksyms, skipping lsmod Oops: 0002 CPU: 0 EIP: 0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: ebx: c16d32f8 ecx: c16d32f8 edx: c023b0c0 esi: c16d32f8 edi: c5b556e4 ebp: esp: c2dbded4 ds: 0018 es: 0018 ss: 0018 Process g++ (pid: 24364, stackpage=c2dbd000) Stack: c16d32f8 c0124c06 c16d32f8 c16d32f8 c0124e6b c16d32f8 c2dbdf18 d38f71c0 dd7c5ba0 c015af38 dd7c5ba0 c2dbdf18 c5b556e4 c63dc140 c0124f27 c5b55640 c028ab40 df56fa20 c0149cf5 c5b556e4 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: ff 48 18 8b 53 04 8b 03 89 50 04 89 02 8b 43 10 c7 43 08 00 >>EIP; c0124b96 <__remove_inode_page+26/60> <= Trace; c0124c06 Trace; c0124e6b Trace; c015af38 Trace; c0124f27 Trace; c0149cf5 Trace; c0147e46 Trace; c013e7d9 Trace; c0140c9a Trace; c013f9aa Trace; c0140d6a Trace; c0111ef0 Trace; c0106edb Code; c0124b96 <__remove_inode_page+26/60> <_EIP>: Code; c0124b96 <__remove_inode_page+26/60> <= 0: ff 48 18 decl 0x18(%eax) <= Code; c0124b99 <__remove_inode_page+29/60> 3: 8b 53 04 mov0x4(%ebx),%edx Code; c0124b9c <__remove_inode_page+2c/60> 6: 8b 03 mov(%ebx),%eax Code; c0124b9e <__remove_inode_page+2e/60> 8: 89 50 04 mov%edx,0x4(%eax) Code; c0124ba1 <__remove_inode_page+31/60> b: 89 02 mov%eax,(%edx) Code; c0124ba3 <__remove_inode_page+33/60> d: 8b 43 10 mov0x10(%ebx),%eax Code; c0124ba6 <__remove_inode_page+36/60> 10: c7 43 08 00 00 00 00 movl $0x0,0x8(%ebx) Ciao, Roland +-+ |Tel.:089/326493320561/873744 | |in Radeberger Weg 8Am Fasanenhof 16| | 85748 Garching 34125 Kassel| +---+-+ |Physik-Department E18 | Raum3558 | |James-Franck-Str. | Telefon 089/289-12592 | |85747 Garching | | +---+-+ | May the Source be with you! | +-+ - 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: Going beyond 256 PCI buses
"Albert D. Cahalan" wrote: > > Tom Gall writes: > > > I was wondering if there are any other folks out there like me who > > have the 256 PCI bus limit looking at them straight in the face? > > I might. The need to reserve bus numbers for hot-plug looks like > a quick way to waste all 256 bus numbers. Hi Albert, yeah I'll be worring about this one too in time. Two birds with one stone wouldn't be a bad thing. Hopefully it doesn't translate into needing a significantly larger stone. > > each PHB has an > > additional id, then each PHB can have up to 256 buses. > > Try not to think of him as a PHB with an extra id. Lots of people > have weird collections. If your boss wants to collect buses, well, > that's his business. Mine likes boats. It's not a big deal, really. Heh PHB==Primary Host Bridge ... but I'll be sure to pass the word onto my PHB that there's a used greyhound sale... Anyway, it really is a new id, at least for the implementation on this box. So PHB0 could have 256 buses, and PHB1 could have 10 buses, PHB2 could have you get the idea. Hot plug would still have the problem in that it'd have 256 bus numbers in the namespace of a PHB to manage. Hot plug under a different PHB would have another 256 to play with. Regards, Tom -- Tom Gall - PPC64 Maintainer "Where's the ka-boom? There was Linux Technology Center supposed to be an earth (w) [EMAIL PROTECTED] shattering ka-boom!" (w) 507-253-4558 -- Marvin Martian (h) [EMAIL PROTECTED] http://www.ibm.com/linux/ltc/projects/ppc - 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: Has it been done: User Script File System?
[EMAIL PROTECTED] said: > Is there any filesystem in Linux that uses user scripts/executables to > implement the various function calls? http://uservfs.sourceforge.net Also, have a look at the hostfs filesystem in UML. It implements a virtual filesystem which provides access to the host filesystems from inside the virtual machine. The userspace side of it is basically trivial to implement and can be used to provide filesystem access to anything on the host that can be made to look like a filesystem. See http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/user-mode-linux/linux/arch/u m/fs/hostfs/hostfs_user.c?rev=1.11=text/vnd.viewcvs-markup for the interface that you'd have to implement. Jeff - 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: [craigl@promise.com: Getting A Patch Into The Kernel] (fwd)
On Wed, 13 Jun 2001, Rob Landley wrote: > Well, you're maintainer and I'm obviously not, but it's nice to hear you've > kept an open mind on this issue. :) I have seen one version and I got physically sick. > > All I want is the API rules to the signatures and we have them now. > > > > We do not need their driver. > > Reinventing the wheel can be fun. Richard Stallman's been doing that for Assuming that the first thing presented was a round one and not the flat-sided square that is being misrepresented. > > Stating/Implying that Linux Maintainers do not care about "quality". > > "Quality" is a loaded word in marketing circles, due to ISO nine zillion and We all know this, and it was their intent to slap around the idea that we lack quality. > You are aware that you were speaking to a marketing person from Promise, > correct? (He admitted it and everything. We didn't even have to use > thumbscrews. Kind of a waste to get them all out and oiled and everything in > that case...) No, because marketing people have at least three faces. > > Oh it gets much worse, but I want to see if the sales for Promise have hit > > hard enough to break their linux-unfriendly additude. > > The dude came hat in hand into the linux-kernel mailing list asking how he > could play nice with us, (apparently honestly not knowing,) and you bit his > head off. Like I said, he is a lamb in a slaughter house that Promise created. It was just this year (late-April) that Promise came "HAT and Hand" and "Knife in the Other" and I got suckered again. > I don't think sales have hit hard enough to overcome THAT just yet. But I > could be wrong... 36 Apr 10 James Baker - PTE (9,744) RE: lack of Linux support hurt sales 37 Apr 11 [EMAIL PROTECTED] (1,243) Re: RE: lack of Linux support hurt sales 38 Apr 11 Daron Keith(10,549) RE: lack of Linux support hurt sales 39 Apr 11 [EMAIL PROTECTED] (1,243) Re: RE: lack of Linux support hurt sales 40 Apr 11 James Baker - PTE (11,069) RE: lack of Linux support hurt sales 41 Apr 11 Daron Keith(33,973) RE: lack of Linux support hurt sales #41 was a VIRUS sent to me to Damage and or Destroy my work. 42 Apr 11 James Baker - PTE (2,944) RE: lack of Linux support hurt sales 43 Apr 11 [EMAIL PROTECTED] (1,243) Re: RE: lack of Linux support hurt sales 44 Apr 11 [EMAIL PROTECTED] (1,249) Re: RE: lack of Linux support hurt sales 45 Apr 11 Billy Harrison (4,691) RE: lack of Linux support hurt sales 46 Apr 11 [EMAIL PROTECTED] (1,249) Re: RE: lack of Linux support hurt sales 47 Apr 11 Daron Keith (6,967) RE: lack of Linux support hurt sales 48 Apr 11 Billy Harrison (7,323) RE: lack of Linux support hurt sales 49 Apr 11 [EMAIL PROTECTED] (1,249) Re: RE: lack of Linux support hurt sales 50 Apr 11 Billy Harrison (10,213) RE: lack of Linux support hurt sales 51 Apr 12 James Baker - PTE (2,339) RE: lack of Linux support hurt sales 52 Apr 12 James Baker - PTE (1,524) Update > > Mind you the came begging for help because their sales are off, and I was > > willing to help on the terms of GPL/GNU and mine. But GPL/GNU was to big > > to choke down. > > Okay, THERE is the problem. Halfway through the message. Why not start with > that next time? Because I am a lamer in email and prefere face to face. > If the problem is that the code will not be made available under the GPL, > then of course that IS an insurmountable problem for getting it included in > the kernel. But it's entirely possible that our marketing friend didn't know > that. It's entirely possible he doesn't know what the GPL -IS-. (If you've > been sharing a private conversation with him that hasn't been CC'd to the > list, than obviously I could be wrong about this...) I am sorry to chuckle but people have lost their jobs at Promise over working with me to bring that company closer to GPL. The guys that this has happened to I offered to help them out but they managed on their own. > > When the sales hurt enough and they have not choice, I will reconsider. > > No, hopefully THEY will reconsider. You couldn't get Linus to accept non-gpl > code either. No, I will reconsider, since we are assuming that they are coming back with two hats, one in each hand. This one hat one hand thing hurts. > > Breathe, because you die before I change my position, if you are hold a > > breath. > > > > I do not trust Promise, and three years of their general arrogance is more > > than enough. > > I honestly doubt that the suit who just wandered through has a clue what the They do not wear "suits", thanks for the laugh! > GPL is. He's not a lawyer, and he doesn't write free software. If he really > was trying to help, and he was new to this, woudn't it be a nice first > impression to clearly say "this licensing issue is blocking the inclusion of > your code" so he knows what the problem is rather than "we're biased against > promise, so we're going
Has it been done: User Script File System?
Is there any filesystem in Linux that uses user scripts/executables to implement the various function calls? What I'm thinking of is something along the lines of a file system module that, when it receives a call from VFS, passes the information out to a user-mode daemon which could then run scripts or executables to answer the question. The daemon would then return the answer to the module, and the module would answer VFS. The reason I'm wondering is that I have a lot of brainstorms about things that might be cool to implement as filesystems, but I don't want to take the time to have to implement a full filesystem for each (especially considering the number of bugs and kernel panics I'm likely to encounter in the process). What I'd really like to do is something like this: mount -t userfs /etc/myfs.conf /myfs Where /etc/myfs.conf would have something like this: lookup: /usr/bin/myfslookup open: /usr/bin/myfsopen etc... I know that it would be very slow, and might require some modifications to VFS to make it work (in addition to the module I'd have to write), but it would be really nice to be able to throw together a very simple utility filesystem without having to worry about crashing the kernel. Does Linux have anything even remotely like this? If not, I might (if I can spare the time) play around with something like this of my own. - 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: threading question
On Tue, Jun 12, 2001 at 12:06:40PM -0700, Kip Macy wrote: > This may sound like flamebait, but its not. Linux threads are basically > just processes that share the same address space. Their performance is > measurably worse than it is on most commercial Unixes and FreeBSD. Thread creation may be a bit slow. But the kludges to provide posix threads completely from userspace also hurt. Notably, they do not scale over multiple CPUs. > They are not, or at least two years ago, were not POSIX compliant > (they behaved badly with respect to signals). The impoverished POSIX threads are silly with respect to signals. I do almost all my programming these days with pthreads and I find that I really do not miss signals at all. > from Larry McVoy's home page attributed to Alan Cox illustrates this > reasonably well: "A computer is a state machine. Threads are for people > who can't program state machines." Sorry for not being more helpful. I got that response too. When I pressed kernel people for details it turns out that they think having hundreds of runnable threads/processes (mostly the same thing under Linux) is wasteful. The scheduler is just not optimised for that. Regards, bert -- http://www.PowerDNS.com Versatile DNS Services Trilab The Technology People 'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Going beyond 256 PCI buses
Tom Gall writes: > I was wondering if there are any other folks out there like me who > have the 256 PCI bus limit looking at them straight in the face? I might. The need to reserve bus numbers for hot-plug looks like a quick way to waste all 256 bus numbers. > each PHB has an > additional id, then each PHB can have up to 256 buses. Try not to think of him as a PHB with an extra id. Lots of people have weird collections. If your boss wants to collect buses, well, that's his business. Mine likes boats. It's not a big deal, really. (Did you not mean your pointy-haired boss has mental problems?) - 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: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T
On Wed, 13 Jun 2001, Ralf Baechle wrote: > On Wed, Jun 13, 2001 at 03:25:22AM -0700, Ion Badulescu wrote: > > Date: Wed, 13 Jun 2001 03:25:22 -0700 > > From: Ion Badulescu <[EMAIL PROTECTED]> > > To: Riley Williams <[EMAIL PROTECTED]> > > Cc: Shawn Starr <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, > > Alan Cox <[EMAIL PROTECTED]> > > Subject: Re: Gigabit Intel NIC? - Intel Gigabit Ethernet Pro/1000T > > > > On Tue, 12 Jun 2001 18:20:58 +0100 (BST), Riley Williams <[EMAIL PROTECTED]> wrote: > > > > > Shawn, I'd suggest you tell the said sales guy that IF he can get you > > > the FULL specs TOGETHER WITH permission to freely distribute them, AND > > > > Permission to freely distribute the specs isn't necessary, although it > > is nice indeed. All that's needed is permission to GPL the driver sources > > written using knowledge from said specs. > > Which would still be a problem. You then have a GPL'ed driver which still > cannot be sanely modified in the way the GPL would like to guarantee. That isn't a problem - the GPL doesn't attempt to guarantee users the INFORMATION needed to make sane changes, just that they have the facility to do so. Just as the kernel doesn't come with a copy of the POSIX specs, the RFCs, etc. - some of the standards the kernel implements aren't available publicly, but that doesn't stop the kernel being freely modifiable! James. - 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/
2.4.5-ac13, APM, and Dell Inspiron 8000
I've been running 2.4.5 on my new Dell I8000 without too many problems. Last night I built -ac13 (on my porch) and booted it without incident. Later, going inside and re-connecting the AC I notice that the thing's hung. I play around a bit and discover that the act of plugging or unplugging the power cord will hang the box. This lead me to disable all power manglement in the BIOS. No joy. This problem does not exist using straight 2.4.5. Has anybody else seen this? Any debugging suggestions? Or stated differently, has anybody with this machine arrived at a configuration that avoids weirdness in the power management framework? In case it's interesting, here's the lspci output: 00:00.0 Host bridge: Intel Corporation 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 02) 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02) 00:1e.0 PCI bridge: Intel Corporation: Unknown device 2448 (rev 03) 00:1f.0 ISA bridge: Intel Corporation: Unknown device 244c (rev 03) 00:1f.1 IDE interface: Intel Corporation: Unknown device 244a (rev 03) 00:1f.2 USB Controller: Intel Corporation 82820 820 (Camino 2) Chipset USB (Hub A) (rev 03) 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility M4 AGP 02:03.0 Multimedia audio controller: ESS Technology ES1983S Maestro-3i PCI Audio Accelerator (rev 10) 02:06.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01) 02:0f.0 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.1 CardBus bridge: Texas Instruments PCI4451 PC card Cardbus Controller 02:0f.2 FireWire (IEEE 1394): Texas Instruments: Unknown device 8027 03:00.0 Ethernet controller: 3Com Corporation 3CCFE575BT Cyclone CardBus (rev 01) - 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: sis630 - help needed debugging in the kernel
> I currently try to debug why the sisfb driver crashes my machine. (SIS 630 > based laptop - linux-2.4.5-ac13). You can do one of two things. Post both System.map and the complete oops or you can run ksymoops on the oops. I can find the problem then. Thanks. > On my serial-console I get: > [...] > sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k > sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k > sisfb: encountered LCD # debug output by me > sisfb: fall back to 1024x768 # debug ouput by me > sisfb: LCD mode # debug output by me > sisfb: mode is 800x600x8, linelength=800 > [...] > Unable to handle kernel paging request at virtual address cc800180 > [oops] > > This happens in the method: register_framebuffer called from sisfb_init. > > I compared the sisfb_init with other framebuffer drivers and can't find what is >wrong. > (I normally don't do kernel hacking...). What does the kernel try to do with the > _io-memory_, mapped around line 2230 in sis_main.c? - Must the memory reqeuested or > mapped in an other way? > > Another strange thing is, that the code seems to work for some people ... > > I would be nice if anyone could give me a hint - because the sis-drivers (kernel and >X) > doesn't work for many people ... > > k33p h4ck1n6 René > > -- > René Rebe (Registered Linux user: #127875) > http://www.rene.rebe.myokay.net/ > -Germany- > > Anyone sending unwanted advertising e-mail to this address will be charged > $25 for network traffic and computing time. By extracting my address from > this message or its header, you agree to these terms. > - > 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] sockreg2.4.5-06 inet[6]_create() register/unregister table
La Monte H.P. Yarroll writes: > Here is the register/unregister inet[6]_create() table patch revised > to disable deregistration and overriding of TCP and UDP. I've applied your patches, thank you. Please enable real tabs in your editor next time though :-) Later, David S. Miller [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SMP module compilation on UP?
Rafael Herrera wrote: > > Mark Mokryn wrote: > > Is it possible to build an SMP module on a machine running a UP kernel > > (or vice versa)? We of course get unresolved symbols during module load > > due to the smp prefix on the ksyms, and haven't seen how to get around > > it. (Defining __SMP__ does not cut it, though I believe this used to > > work a while ago). > > Yes. It does not matter what kernel you are running. What's important is > that you configure your sources. Configure your kernel for SMP and do a > 'make dep', then compile your module. > -- > Rafael Is this the only way - to keep two separately configured kernel source trees? No way to do it via some flag? thanks, -mark - 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: Client receives TCP packets but does not ACK
On 13 Jun 2001, Andi Kleen wrote:
> The packet likely doesn't fit into the socket buffer and is silently
> dropped. The TCP stack doesn't force an ACK in this case, but it
> probably should, although it wouldn't solve the deadlock. The deadlock
> will be only solved if the local application reads data and clears the
> socket buffer. If you have a single packet that is bigger than the
> empty socket buffer / 2 you lose.
>
> You can check the allocated socket buffer size using netstat.
Thanks for the quick response!
I tried most of the netstat options and was unable to see the buffer size.
I do see the Recv-Q and the Send-Q which are usually zero except when the
client stops ack-ing and then the server's Send-Q starts filling up.
> You can increase it using the /proc/sys/net/core/rmem_{default,max}
> sysctls; in 2.4 there is also a TCP memory limit that can be tuned
> using /proc/sys/net/ipv4/tcp_mem. Doubling one of these will probably
> fix your problems.
On the client:
/proc/sys/net/core/rmem_default = 65535
/proc/sys/net/core/rmem_max = 65535
/proc/sys/net/ipv4/tcp_mem = 48128 48640 49152
On the server:
/proc/sys/net/core/rmem_default = 65535
/proc/sys/net/core/rmem_max = 65535
/proc/sys/net/ipv4/tcp_mem = 23552 24064 24576
The "bad" packet that seems to cause all the problems is only 1448
bytes long so I don't think insufficient buffers is the problem.
After the client stops ack-ing I can watch the server's Send-Q slowly
rise 2K, 4K, 6K, but it never comes close to these buffer limits.
Robert.
-
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/
Going beyond 256 PCI buses
Anyway, Hi All, I was wondering if there are any other folks out there like me who have the 256 PCI bus limit looking at them straight in the face? If so, it'd be nice to collaborate and come up with a more general solution that would hopefully work towards the greater good. I live in ppc64 land which is a new arch that the linux kernel has been ported to. The boxes we run on tend to be big. The box that I'm wrestling with, has a setup where each PHB has an additional id, then each PHB can have up to 256 buses. So when you are talking to a device, the scheme is phbid, bus, dev etc etc. Pretty easy really. I am getting for putting something like this into the kernel at large, it would probably be best to have a CONFIG_GREATER_THAN_256_BUSES or some such. Anyways, thoughts? opinions? -- Hakuna Matata, Tom --- ppc64 Maintainer IBM Linux Technology Center "My heart is human, my blood is boiling, my brain IBM" -- Mr Roboto [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/
Re: [craigl@promise.com: Getting A Patch Into The Kernel] (fwd)
On Wednesday 13 June 2001 03:06, Andre Hedrick wrote: > No I would not take their code and apply it. > I might not even want to look at it. Well, you're maintainer and I'm obviously not, but it's nice to hear you've kept an open mind on this issue. :) > All I want is the API rules to the signatures and we have them now. > > We do not need their driver. Reinventing the wheel can be fun. Richard Stallman's been doing that for years since he refuses to take any patch where he can't physically track down the author and make them sign a piece of paper handing the copyright over to the Free Software Foundation. (He's got a file cabinet full of them so he'll have unassailable standing in case he ever has to sue anybody to enforce the GPL on GNU code.) Of course the unfortunate side effect of this is that the GNU project stalled in the late 1980's, and this whole "Linux" think forked off of it and took over instead, in large part because there was just too much friction getting patches through the maintainer bottleneck, while Linus would accept anything from anybody. (Linus sucked all the developers away from comp.os.minix for the same reason.) But oh well. > Next insults to linux in this form are unacceptable means of > communication. > ... insult omitted > > Stating/Implying that Linux Maintainers do not care about "quality". "Quality" is a loaded word in marketing circles, due to ISO nine zillion and the sickening-sigma stuff and all that. I always think of it in terms of "the most prominent qualities of this product are that it smells bad and tends to explode without warning. Now wrap that up in flowers and make it sound good." And off the marketing droids go... You are aware that you were speaking to a marketing person from Promise, correct? (He admitted it and everything. We didn't even have to use thumbscrews. Kind of a waste to get them all out and oiled and everything in that case...) > Oh it gets much worse, but I want to see if the sales for Promise have hit > hard enough to break their linux-unfriendly additude. The dude came hat in hand into the linux-kernel mailing list asking how he could play nice with us, (apparently honestly not knowing,) and you bit his head off. I don't think sales have hit hard enough to overcome THAT just yet. But I could be wrong... > Mind you the came begging for help because their sales are off, and I was > willing to help on the terms of GPL/GNU and mine. But GPL/GNU was to big > to choke down. Okay, THERE is the problem. Halfway through the message. Why not start with that next time? If the problem is that the code will not be made available under the GPL, then of course that IS an insurmountable problem for getting it included in the kernel. But it's entirely possible that our marketing friend didn't know that. It's entirely possible he doesn't know what the GPL -IS-. (If you've been sharing a private conversation with him that hasn't been CC'd to the list, than obviously I could be wrong about this...) > When the sales hurt enough and they have not choice, I will reconsider. No, hopefully THEY will reconsider. You couldn't get Linus to accept non-gpl code either. > Breathe, because you die before I change my position, if you are hold a > breath. > > I do not trust Promise, and three years of their general arrogance is more > than enough. I honestly doubt that the suit who just wandered through has a clue what the GPL is. He's not a lawyer, and he doesn't write free software. If he really was trying to help, and he was new to this, woudn't it be a nice first impression to clearly say "this licensing issue is blocking the inclusion of your code" so he knows what the problem is rather than "we're biased against promise, so we're going to pick on you and call you names?" > Mind you that at one point I had two people in the San Jose > office that were friendly be they are now gone. If you've approached every new person from promise this way ever since, I'm not exactly suprised you haven't met more like them. (I honestly hope that the previous sentence was a harsh and unfair assessment, and that you haven't been doing that.) No corporation is truly a monolithic entity. It's just a bunch of disjointed individuals who spend a lot of time in meetings filling out forms. You can deal with them as a faceless professional with a known set of duties, or you can try to deal with them as a human being. (Either way has been known to work, a bit like having two interfaces for the same object in Java. I learned that working at IBM. Plus the concepts of plausible deniability, least expected effort, a sort of judo approach to political infighting, that forgiveness is an order of magnitude easier to get than permission because punishing you takes effort, turning uncertainty to your advantage through the power of procrastination, and that everything I've seen so far in dilbert is less than 5% off
3C905B -- EEPROM (i blive so) problem
Hi, I have a 3COM 3C905B ethernet card that has been hit by a power outage for aprox. 0.5 sec. Now, the kernel does not recongnize the card anymore. When I do lspci, I see 3COM Ethernet controller, type unknown 0xff (rev 3x). The bios reports the card as an ethernet card at system boot-up. I run the diagnostic program for 3com cards from Donald Becker and all the card registers are and . I do belive something happened to the eeprom of the card. I would like to know if I can overwrite-it with a new one so that I can make my ethernet card work again. Thank you, Eugen - 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 module compilation on UP?
Mark Mokryn wrote: > Is it possible to build an SMP module on a machine running a UP kernel > (or vice versa)? We of course get unresolved symbols during module load > due to the smp prefix on the ksyms, and haven't seen how to get around > it. (Defining __SMP__ does not cut it, though I believe this used to > work a while ago). Yes. It does not matter what kernel you are running. What's important is that you configure your sources. Configure your kernel for SMP and do a 'make dep', then compile your module. -- Rafael - 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/
FYI: ECN approved as Standard
The IESG approved ECN as a proposed standard on the 12th of June. That means as of now, anyone blocking ECN bits is considered to be blaspheming. cheers, jamal - 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/
sis630 - help needed debugging in the kernel
Hi all! I currently try to debug why the sisfb driver crashes my machine. (SIS 630 based laptop - linux-2.4.5-ac13). On my serial-console I get: [...] sisfb: framebuffer at 0xe000, mapped to 0xcb80, size 16384k sisfb: MMIO at 0xefce, mapped to 0xcc801000, size 128k sisfb: encountered LCD # debug output by me sisfb: fall back to 1024x768 # debug ouput by me sisfb: LCD mode # debug output by me sisfb: mode is 800x600x8, linelength=800 [...] Unable to handle kernel paging request at virtual address cc800180 [oops] This happens in the method: register_framebuffer called from sisfb_init. I compared the sisfb_init with other framebuffer drivers and can't find what is wrong. (I normally don't do kernel hacking...). What does the kernel try to do with the _io-memory_, mapped around line 2230 in sis_main.c? - Must the memory reqeuested or mapped in an other way? Another strange thing is, that the code seems to work for some people ... I would be nice if anyone could give me a hint - because the sis-drivers (kernel and X) doesn't work for many people ... k33p h4ck1n6 René -- René Rebe (Registered Linux user: #127875) http://www.rene.rebe.myokay.net/ -Germany- Anyone sending unwanted advertising e-mail to this address will be charged $25 for network traffic and computing time. By extracting my address from this message or its header, you agree to these terms. - 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 data corruption
On Tue, Jun 12, 2001 at 01:17:49PM -0700, Larry McVoy wrote: > Folks, I believe I have a reproducible test case which corrupts data in > 2.4.5. Why don't you send the test case to the list? I would love to try it out and it would be a good addition to LTP. -- Nate Straz [EMAIL PROTECTED] sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.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: Hour long timeout to ssh/telnet/ftp to down host?
On Wednesday 13 June 2001 05:40, Luigi Genoni wrote: > On Tue, 12 Jun 2001, Ben Greear wrote: > > You can tune things by setting the tcp-timeout probably..I don't > > know exactly where to set this.. > > /proc/sys/net/ipv4/tcp_fin_timeout > > default is 60. Never got that far. My problem was actually tcp_syn_retries. Remember, I was talking to a host that was unplugged. (I wasn't even getting "host unreachable" messages, the packets were just disappearing.) The default timeout in that case is rediculous do to the exponentially increasing delays between retries. 10 retries wound up being something like 20 minutes. I set it to 5 and everything works beautifully now. ssh (which retries the connection 4 times, and used to take over an hour to time out) now takes just over 3 minutes, which I can live with. 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/
SMP module compilation on UP?
Hi, Is it possible to build an SMP module on a machine running a UP kernel (or vice versa)? We of course get unresolved symbols during module load due to the smp prefix on the ksyms, and haven't seen how to get around it. (Defining __SMP__ does not cut it, though I believe this used to work a while ago). Please reply to me as well as to the list. Thanks, -mark - 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: threading question
Solaris has pset_create() and pset_bind() where you can bind LWPs to
specific processors, but I doubt this works on anything else
Best regards,
Ognen
On Wed, 13 Jun 2001, Philips wrote:
> BTW.
> Question was poping in my mind and finally got negative answer by my mind ;-)
>
> Is it possible to make somethis like:
>
>
> char a[100] = {...}
> char b[100] = {...}
> char c[100];
> char d[100];
>
> 1: { // run this on first CPU
> for (int i=0; i<100; i++) c[i] = a[i] + b[i];
> };
> 2: { // run this on any other CPU
> for (int i=0; i<100; i++) d[i] = a[i] * b[i];
> };
>
> ...
> // do something else...
> ...
>
> wait 1,2; // to be sure c[] and d[] are ready.
>
>
> what was popping in my mind - some prefix (like 0x66 Intel used for 32
> instructions) to say this instruction should run on other CPU?
> I know - stupid idea. Too many questions will arise.
> If we will do
>
> PREFIX jmp far some_routing
>
> and this routing will run on other CPU not blocking current execution thread.
> (who will clean stack? when?.. question without answers...)
>
> Is there anything like this in computerworld? I heard about old computers that
> have a speacial instruction set to implicit run code on given processor.
> Is it possible to emulate this behavior on PCs?
--
Ognen Duzlevski
Plant Biotechnology Institute
National Research Council of Canada
Bioinformatics team
-
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] 2.4.6-pre3 unresolved symbol do_softirq
On Wed, Jun 13, 2001 at 04:44:40PM +0200, Andreas Schwab wrote: > Use %c0. *Note Output Templates and Operand Substitution: (gcc)Output > Template. Oh great! I can get rid of some more crap from the ARM tree! Thanks. -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.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: [patch] 2.4.6-pre3 unresolved symbol do_softirq
On Wed, Jun 13, 2001 at 07:21:41AM -0700, David S. Miller wrote:
> I can't believe there is no reliable way to get rid of that
> pesky "$" gcc is adding to the symbol. Oh well...
GCC on ARM does a similar thing - all constants in the assembler are
prefixed with '#' or '@'. Using the 'i' constraint adds this. This
behaviour is actually useful when you want to pass a constant or a
register - it allows GCC to make the decision for you, and do the
right thing in the assembler fragment. Eg, the following code used
to be in the kernel until 2.3:
extern __inline__ void __outb (unsigned int value, unsigned int port)
{
unsigned long temp;
__asm__ __volatile__(
"tst%2, #0x8000\n\t"
"mov%0, %4\n\t"
"addeq %0, %0, %3\n\t"
"strb %1, [%0, %2, lsl #2]@ outb"
: "=" (temp)
: "r" (value), "r" (port), "Ir" (PCIO_BASE - IO_BASE), "Ir" (IO_BASE)
: "cc");
}
%3 and %4 might be a constant:
mov r5, #0x0300
or a real register if the constant can't be loaded in one instruction:
mov r5, r1
'I' in this case means "a constant suitable for use with the arithmetic
instructions".
--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.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: [patch] 2.4.6-pre3 unresolved symbol do_softirq
"David S. Miller" wrote:
>
> Keith Owens writes:
> > #define my_symbol my_symbol_versioned
> > extern void my_symbol(void);
> >
> > void foo(void) { __asm__("call %0" : : "i" (my_symbol)); }
> >
> > # gcc -o x x.c
> > /tmp/cclWXduj.s: Assembler messages:
> > /tmp/cclWXduj.s:12: Error: suffix or operands invalid for `call'
>
> I can't believe there is no reliable way to get rid of that
> pesky "$" gcc is adding to the symbol. Oh well...
void foo(void) { __asm__("call %c0" : : "i" (my_symbol)); }
^^^
-
-
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/
