Re: japanese keyboards
> Recently I got some more detailed information on Japanese keyboards > and their scancodes. Maybe there are Japanese readers here who > can look at > http://www.win.tue.nl/~aeb/linux/kbd/scancodes-3.html#ss3.3 > and correct what is wrong? > > Andries Well, I can read Japanese, but what exactly is the problem? I haven't found anything wrong with my Japanese keyboard that would need to be fixed in the kernel. Could you give some more details? -- Bruce Harada [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/
Compaq launches Open SSI Cluster Projects
Compaq has launched two open source technology projects under the GPL license. They are briefly described below and can be found through www.opensource.compaq.com. We are actively looking for technology partners, contributors, consultants and general kibitzers to participate via the email lists set up for each project. Those that just want to monitor the projects are welcome as well. Cluster Infrastructure for Linux (CI) The goal of this project is to develop a common infrastructure for many if not all forms of Linux clustering by extending the Cluster Membership and Inter-node Communication Subsystems from Compaq's NonStop Clusters for Unixware code base. This project also provides the basis for the Open SSI Clusters for Linux project. A developers download is available via www.opensource.compaq.com for Intel-32, along with build, boot, hook, interface and api documentation. We will put the CVS repository on the web when we can. A port to the alpha chip has already succeeded and patches for that are available. Open Single System Image (SSI) Clusters for Linux Project The Open SSI project leverages both Compaq's NonStop Clusters for Unixware technology and other open source technology to provide a full, highly available SSI environment for Linux. Goals for SSI Clusters include availability, scalability and manageability, built from standard servers. Technology pieces will include: membership, single root and single init, cluster filesystems and DLM, single process space and process migration, load leveling, availability monitors and failover, single namespace and shared access for all forms of IPC, devices and networking, and a single management space. The SSI project will leverage the Cluster Infrastructure for Linux project. Source beyond the CI base is not yet available. We are aiming for a developers release of much of functionality in July. In the meantime there is a presentation on SSI Clustering on the web. An initial list of component requirements will soon be posted for discussion and refinement. Join the mail alias via www.opensource.compaq.com to stay updated. bruce walker SSI Cluster Architect Linux Program Office Compaq Computers - 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-ac5 locks on ReiserFS umount (ac4 doesn't)
On Fri, 1 Jun 2001 18:34:46 -0400 (EDT) Pavel Roskin <[EMAIL PROTECTED]> wrote: > Another problem is that the archive at > http://www.uwsg.indiana.edu/hypermail/linux/kernel/ updates only once a > day. I checked it and decided that my information could still be useful. > > I'd be grateful if somebody pointed me to a better archive. Try http://www.lib.uaa.alaska.edu/linux-kernel/ - it updates in pretty close to real-time, and you can search the archives as well. Bruce - 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: is there a linux running on jvm arch ?
>I 've tested the User Mode Linux a few times ago, and it gave me an >idea: given the fact that we had a GCC which >produce bytecode from C, it would be possible to produce a port of >linux(a new directory "jvm" in the arch dir) which >would run in a Java Virtual Machine. (after some inquiries such compiler >does not exist :-( ) >I'm dreaming of a linux booting in a browser applet(imagine sending such >thing in a mail to MS peoples ) While I am not sure if this is possible with Linux, something like this has already been done with Inferno. Check out: http://www.vitanuova.com/inferno/pidoc/index.html B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: The latest Microsoft FUD. This time from BillG, himself.
>Did I mention I'm writing a book on all this? (The history of linux and the >computer industry, going back to World War II...) This makes me the only >person I know who's excited about finding ~50 issues of "Compute" and >"Compute's gazette" from the mid 80's at a garage sale. An the university of >texas's library has been quite a help. So have the used book stores... If your interested in old magazines, I had saved literally dozens of 80's computer magazines, Compute, Computes Gazette, and some others. I just cleaned up the house, but may have some left. I didn't think anyone was interested in this stuff, and threw a bunch away. I would be happy to donate them if I have some left. Let me know offline, as this sounds like an interesting project. B. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Oops error
Hello Sorry I had to send this to the whole developer list - there wasn't much in the output of ksymoops that told me who to send it to. Here's the background in case this is useful: I have a background process that plays mp3's through amp. After one finished and another tried to start, I got the oops and the mp3 never played (it went on to the next one). The mp3 was on a UDF CD-RW, and the next one it played was on the hard drive. Soon thereafter I noticed that all mp3's had stopped and that any process that tried to read anything from /cdrom (including ls /cdrom) went into daemon state and refused to die, even with kill -9. I'm guessing that this means the problem is in either the CD-ROM code or the UDF code, but it might be unrelated. I've attached the output from ksymoops. B4N Bruce /----\ | Bruce Merry (Entropy)| bmerry at iafrica dot com | | Proud user of Linux! | http://www.cs.uct.ac.za/~bmerry | | Disc space -- the final frontier! | \/ ksymoops 2.3.4 on i686 2.4.0-test8. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.0-test8/ (default) -m /usr/src/linux/System.map (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Sep 11 19:31:10 cheese kernel: Oops: Sep 11 19:31:10 cheese kernel: CPU:0 Sep 11 19:31:10 cheese kernel: EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 Sep 11 19:31:10 cheese kernel: EFLAGS: 00010246 Sep 11 19:31:10 cheese kernel: eax: c2da4080 ebx: c3bf9ca0 ecx: 0008 edx: 07e81b13 Sep 11 19:31:10 cheese kernel: esi: c2ad edi: 0005 ebp: esp: c2de1ccc Sep 11 19:31:10 cheese kernel: ds: 0018 es: 0018 ss: 0018 Sep 11 19:31:10 cheese kernel: Process amp (pid: 366, stackpage=c2de1000) Sep 11 19:31:10 cheese kernel: Stack: c3bf9ca0 c2ad8400 fd036273 c2de1d64 c2de1d08 c4851f0f Sep 11 19:31:10 cheese kernel:c2ad8400 fd036273 c3df9800 c378f5e0 Sep 11 19:31:10 cheese kernel:c484f25f c2ad8400 fd036273 c28d1860 c3df9800 Sep 11 19:31:10 cheese kernel: Call Trace: [] [] [] [] [] [] [tcp_v4_send_check+45/112] Sep 11 19:31:10 cheese kernel:[] [do_no_page+84/256] [d_alloc+21/368] [real_lookup+79/224] [path_walk+614/2144] [open_namei+118/1360] [filp_open+49/112] [getname+104/176] Sep 11 19:31:10 cheese kernel: Code: 0f b6 14 02 eb 3b 8d b6 00 00 00 00 8d bc 27 00 00 00 00 80 >>EIP; c485223d <[sb]__module_parm_desc_acer+3ae5/b908> <= Trace; fd036273 Trace; c4851f0f <[sb]__module_parm_desc_acer+37b7/b908> Trace; fd036273 Trace; c484f25f <[sb]__module_parm_desc_acer+b07/b908> Trace; fd036273 Trace; fd036273 Trace; c484f5b1 <[sb]__module_parm_desc_acer+e59/b908> Code; c485223d <[sb]__module_parm_desc_acer+3ae5/b908> <_EIP>: Code; c485223d <[sb]__module_parm_desc_acer+3ae5/b908> <= 0: 0f b6 14 02 movzbl (%edx,%eax,1),%edx <= Code; c4852241 <[sb]__module_parm_desc_acer+3ae9/b908> 4: eb 3b jmp41 <_EIP+0x41> c485227e <[sb]__module_parm_desc_acer+3b26/b908> Code; c4852243 <[sb]__module_parm_desc_acer+3aeb/b908> 6: 8d b6 00 00 00 00 leal 0x0(%esi),%esi Code; c4852249 <[sb]__module_parm_desc_acer+3af1/b908> c: 8d bc 27 00 00 00 00 leal 0x0(%edi,1),%edi Code; c4852250 <[sb]__module_parm_desc_acer+3af8/b908> 13: 80 00 00 addb $0x0,(%eax) 1 warning issued. Results may not be reliable.
Re: Driver for Casio Cassiopia Fiva touchscreen, help with conversion
On Wed, 14 Feb 2001 12:04:41 + (GMT) Alan Cox <[EMAIL PROTECTED]> wrote: > Thats pretty much how we did the pc110 pad driver too. This is getting off-topic, but I was wondering - does the pc110 pad driver still work? I seem to recall trying it around 2.2.9 or so, and eventually giving up. (Not that it's vital or anything, but I have three of the little things lying around here that I keep on telling myself I'm going to use one day...) And while we're on the topic, toy.cabi.net is still listed in Configure.help as the location for the pc110 pad driver docs, but it doesn't resolve for me... -- Bruce Harada [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: binfmt_script and ^M
On Tue, 27 Feb 2001 14:38:23 +0100 Ivo Timmermans <[EMAIL PROTECTED]> wrote: > Heusden, Folkert van wrote: > > > When running a script (perl in this case) that has DOS-style > newlines > > > (\r\n), Linux 2.4.2 can't find an interpreter because it doesn't > > > recognize the \r. The following patch should fix this (untested). > > > > _should_ it work with the \r in it? > > IMHO, yes. This set of files were created on Windows, then zipped and > uploaded to a Linux server, unpacked. This does not change the \r. Unzipping the files with the "-ll" option should fix that. There's no particular reason why the kernel should handle CR+LF; LF has been the end-of-line character for UN*X systems since Adam was a cowboy. Changing it now would only lead to a situation where some things would work with CR+LF and others wouldn't. Let's keep it simple... -- Bruce Harada [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: AC6 crash
On Wed, 28 Feb 2001 16:19:02 +0100 (CET) Wouter Schoot <[EMAIL PROTECTED]> wrote: > Hello, > > I entered make menuconfig with 2.4.2 patched with AC6. > I run 2.4.2 AC2 at the moment, and unpacked 2.4.2 and AC6 from the > scratch > > > Menuconfig has encountered a possible error in one of the kernel's > configuration files and is unable to continue. Here is the error > report: [SNIP] Just a couple of things - when sending mail to l-k, it's probably better to give it an accurate subject. "AC6 crash" sounds like 2.4.2ac6 crashed while you were running it; something like "ac6 menuconfig failure" would have been better. The other point is, this problem has already popped up at least three times in the last couple of days (maybe more, I'm not keeping track). A solution has also been posted multiple times. Before posting, you might want to check one of the l-k archives (just do a search at http://www.google.com/ - several should be at the top of the list). Some of them are updated in almost real-time, so even very recent questions will appear. Anyway, the answer to your problem is: --- 2.9/arch/i386/config.in Wed, 28 Feb 2001 12:44:01 +1100 kaos (linux-2.4/T/c/36_config.in 1.1.2.1.1.2 644) +++ 2.9(w)/arch/i386/config.in Wed, 28 Feb 2001 12:46:03 +1100 kaos +(linux-2.4/T/c/36_config.in 1.1.2.1.1.2 644) @@ -379,6 +379,6 @@ bool ' Memory mapped I/O debugging' CON bool ' Magic SysRq key' CONFIG_MAGIC_SYSRQ bool ' Spinlock debugging' CONFIG_DEBUG_SPINLOCK bool ' Verbose BUG() reporting (adds 70K)' CONFIG_DEBUG_BUGVERBOSE -endmenu - fi + +endmenu This is a patch from Keith Owens. Alternatively, there appears to be an incremental patch from ac5 up at: http://www.bzimage.org/kernel-patches/v2.4/alan/v2.4.2/patch-2.4.2-ac5-ac6.bz2 which also fixes the EXTRAVERSION problem (it's still at ac5). -- Bruce Harada [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: IMS Twin Turbo 128 framebuffer
On Fri, 2 Mar 2001 20:32:31 -0300 John R Lenton <[EMAIL PROTECTED]> wrote: > Is there any particular reason why imsttfb isn't available in the > i386 arch? I believe it's because the Twin Turbo was introduced into the kernel via the PPC kernel port - was there actually a TT board for PCs? I'm not talking about bus (the TTs were all PCI, IIRC), but rather the firmware on the board - does it work on x86? If not, can it be flashed? If it can't, you're out of luck. -- Bruce Harada [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/
2.4.0-ac3 oneliners
Hi Alan,
These are just a few unused variables that popped up as warnings from
2.4.0-ac3 (I've also (briefly) checked ac4, and didn't notice any changes
in there). Here's hoping that I'm not breaking something...
--
Bruce Harada
[EMAIL PROTECTED]
diff -Nur linux-2.4.0-ac3/drivers/net/tulip/media.c
linux-2.4.0-ac3-bh1/drivers/net/tulip/media.c
--- linux-2.4.0-ac3/drivers/net/tulip/media.c Tue Jan 2 02:54:07 2001
+++ linux-2.4.0-ac3-bh1/drivers/net/tulip/media.c Mon Jan 8 21:28:50 2001
@@ -265,7 +265,6 @@
}
case 5: case 6: {
u16 setup[5];
- u32 csr13val, csr14val, csr15dir, csr15val;
for (i = 0; i < 5; i++)
setup[i] = get_u16(&p[i*2 + 1]);
diff -Nur linux-2.4.0-ac3/mm/filemap.c linux-2.4.0-ac3-bh1/mm/filemap.c
--- linux-2.4.0-ac3/mm/filemap.cMon Jan 8 21:19:58 2001
+++ linux-2.4.0-ac3-bh1/mm/filemap.cMon Jan 8 21:22:14 2001
@@ -2499,7 +2499,7 @@
mark_inode_dirty_sync(inode);
while (count) {
- unsigned long bytes, index, offset, partial = 0;
+ unsigned long bytes, index, offset;
char *kaddr;
int deactivate = 1;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: aic7xxx hangs 2.4.0 with SMP
[1] aic7xxx hangs 2.4.0 with SMP [2] SCSI device errors that only occur in a SMP machine with an aic7xxx with 2.4.0. The problem manifests itself with multiple SCSI bus resets and data error. [3] SMP SCSI aic7xxx [4] Linux version 2.4.0 ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #5 SMP Sun Jan 14 10:01:24 EST 2001a [5] N/A [6] N/A [7] N/A [7.1] Linux shockwave.linux2go.org 2.4.0 #5 SMP Sun Jan 14 10:01:24 EST 2001 i686 unknown Kernel modules 2.3.16 Gnu C egcs-2.91.66 Gnu Make 3.77 Binutils 2.9.1.0.24 Linux C Library2.1.3 Dynamic linker ldd (GNU libc) 2.1.3 Procps 2.0.4 Mount 2.9u Net-tools 1.57 Console-tools 1999.03.02 Sh-utils 2.0 Modules Loaded tvaudio bttv msp3400 tuner i2c-algo-bit i2c-core videodev rtc ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE iptable_filter iptable_nat ip_conntrack ip_tables vmnet vmmon eepro100 st nls_iso8859-1 nls_cp437 vfat fat es1371 ac97_codec soundcore unix [7.2] processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 551.255 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1101.00 processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 3 cpu MHz : 551.255 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips: 1101.00 [7.3] tvaudio 8208 0 (autoclean) (unused) bttv 57904 2 (autoclean) msp340013904 0 (autoclean) (unused) tuner 3296 1 (autoclean) i2c-algo-bit7296 2 (autoclean) [bttv] i2c-core 12112 0 (autoclean) [tvaudio bttv msp3400 tuner i2c-algo-bit] videodev4960 6 (autoclean) [bttv] rtc 6320 0 (unused) ip_nat_ftp 4080 0 (unused) ip_conntrack_ftp2560 0 [ip_nat_ftp] ipt_MASQUERADE 2048 1 (autoclean) iptable_filter 1920 0 (autoclean) (unused) iptable_nat19520 1 [ip_nat_ftp ipt_MASQUERADE] ip_conntrack 22848 2 [ip_nat_ftp ip_conntrack_ftp ipt_MASQUERADE iptable_nat] ip_tables 13216 5 [ipt_MASQUERADE iptable_filter iptable_nat] vmnet 16960 3 vmmon 18288 0 (unused) eepro100 17312 1 (autoclean) st 27664 0 (unused) nls_iso8859-1 2832 5 (autoclean) nls_cp437 4352 5 (autoclean) vfat 11696 5 (autoclean) fat32480 0 (autoclean) [vfat] es1371 31056 5 (autoclean) ac97_codec 7952 0 (autoclean) [es1371] soundcore 3920 4 (autoclean) [es1371] unix 16816 116 (autoclean) [7.4] -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 02e8-02ef : serial(set) 02f8-02ff : serial(auto) 03c0-03df : vga+ 03f6-03f6 : ide0 0400-043f : Intel Corporation 82371AB PIIX4 ACPI 0800-081f : Intel Corporation 82371AB PIIX4 ACPI 0cf8-0cff : PCI conf1 9000-9fff : PCI Bus #01 9000-90ff : 3Dfx Interactive, Inc. Voodoo 3 a000-afff : PCI Bus #02 a000-a0ff : Adaptec 7896 a000-a0fe : aic7xxx a400-a4ff : Adaptec 7896 (#2) a400-a4fe : aic7xxx b000-b03f : Ensoniq ES1371 [AudioPCI-97] b000-b03f : es1371 b0c0-b0df : Intel Corporation 82557 [Ethernet Pro 100] b0c0-b0df : eepro100 b400-b41f : Intel Corporation 82371AB PIIX4 USB b440-b44f : Intel Corporation 82371AB PIIX4 IDE b440-b447 : ide0 -0009efff : System RAM 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000e-000e : Extension ROM 000f-000f : System ROM 0010-1fff : System RAM 0010-001ea9c5 : Kernel code 001ea9c6-0023a55f : Kernel data 8010-840f : PCI Bus #01 8200-83ff : 3Dfx Interactive, Inc. Voodoo 3 8410-841f : PCI Bus #02 8410-84100fff : Adaptec 7896 84101000-84101fff : Adaptec 7896 (#2) 8430-880f : PCI Bus #01 8600-87ff : 3Dfx Interactive, Inc. Voodoo 3 8810-881f : PCI Bus #02 8810-88100fff : Brooktree Corporation Bt878 (#2) 8810-88100fff : bttv 8
Re: [PATCH] CPU hot swap for 2.4.3 + s390 support
> > >How far away is the capability to "teleport" processes from one machine to > > >another over the network? Think of the uptime! > > > > > > > It is here. Look at Mosix. > > No. Not for uptime. > > The "responsibility" for process completion does not get delegated. A process > will always be bound to it's home-node (in mosix terms), no matter how far > it's "teleported". If the home-node fails, the process won't know what hit > it. > > There are good reasons why mosix let's processes depend on their home nodes. > > This is not meant as backstabbing mosix, it's a great environment for a lot > of things. > > But it's not the universal silver bullet. Take a look at http://citeseer.nj.nec.com/299905.html for something along the lines of what you want, I think (transparent process migration between nodes). As a bonus, it's also architecture-independent. Bruce - 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 Scalability, Samba, and Netbench
Andrew Theurer wrote: > I do have kernprof ACG and lockmeter for a 4P run. We saw no > significant problems with lockmeter. csum_partial_copy_generic was the > highest % in profile, at 4.34%. I'll see if we can get some space on > http://lse.sourceforge.net to post the test data. The Netfinity system that you are using has two different supported GigE adapters. I assume you are using one of these types - Netfinity Gigabit Ethernet Adapter (19K4401) and the Netfinity Gigabit Ethernet SX Server Adapter (06P3701); using the acenic.c and e1000.c drivers, respectively. >From what I understand after initial perusal of the two drivers, the former has receive checksumming support on the adapter itself while the latter, the one you are using, does not support hardware checksumming (at least, it is not enabled by the driver). Are you able to re-run your tests with GigE adapters that support checksumming on the hardware instead of doing it in the kernel? If not, I will be running similar tests in a very similar configuration (with the 19K4401 adapters) in the near future and can share results if you'd like. Bruce Allan/Beaverton/IBM IBM Linux Technology Center - OS Gold 503-578-4187 T/L 775-4187 [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: DMA support for toshiba IDE controllers
On Fri, 18 May 2001 11:15:09 -0700 (PDT) Alex Deucher <[EMAIL PROTECTED]> wrote: > Does anyone know if there is any DMA support for the > toshiba IDE controller's in many of their portable > models such as the older porteges and librettos? The > controllers support DMA, but not in linux. I'm not > sure what toshiba's policy is on documentation. They > used to be pretty stingy, but I heard they have > recently opened up of lot of their doc's, like the > oboe IR controller for instance. Well, Toshiba Japan has a Linux developers' page (in Japanese): http://linux.toshiba-dme.co.jp/linux/jpn/develop.php3 According to that page, their mail address for requests from developers is: [EMAIL PROTECTED] so if you don't get any satisfaction from Toshiba USA/Europe/wherever you're living, try asking Toshiba Japan (they do ask that you be specific, so if you send them a request, make sure to state exactly which models/chipsets, etc., you're interested in, and remember that they might take a while to reply to email in English). They do seem to be quite good lately about releasing documentation - Dag Brattli got some info on the IrDA hardware they use, and the Japan Linux Association has got docs for the ToPIC PC Card controller out of them, too. The only time they've actually turned someone down (according to that page, anyway) is when the hardware in question included third-party technology. Bruce - 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: APIC errors ...
On Wed, 18 Apr 2001 15:21:17 -0700 (PDT) "Dr. Kelsey Hudson" <[EMAIL PROTECTED]> wrote: *snip* > You have a couple solutions: Upgrade the motherboard to one of the VIA > 133MHz chipsets (I dont care for the VIA chipset so this really doesn't > strike my fancy) or upgrade to that other Intel chipset that supports SMP; > unfortunately it also is a rambus boardServerworks also has a chipset > out that does dual intel chips at 133MHz; I've heard only good things > about it. Er... I believe there was some discussion on l-k some while ago regarding a certain lack of forthcomingness by Serverworks and the resultant general flakiness of Linux support for their chipsets... - 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: Tiny little problem
Hi. This is a well-known problem; check the list archives for more info. On Thu, 26 Apr 2001 14:04:23 +0900 (JST) Tore Johansson <[EMAIL PROTECTED]> wrote: > Hi, > > I have a problem with accessing a magneto opto drive in Linux. > Since I upgraded the kernel from 2.3 to 2.4 I can mount the MO > drive but if I try to access a file on the drive the kernel oopses... > > After the kernel oops the MO can't be unmounted. > > The MO is has a SCSI-2 interface and the SCSI interface is a Symbios > NCR8xx type. > > Any ideas?? > > Cheers, > /Tore - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [OT] Wild thangs, was: sendmail fails to deliver mail with attachments in /var/spool/mqueue
On Fri, Nov 10, 2000 at 04:28:11PM -0800, David Ford wrote: > Some wild blatherings about sendmail... Warning: the following will likely be seen by some as flamebait. I've long ago divorced myself from sendmail to save my own sanity. > - Uses lots of memory to send a big file. > Incorrect. I just verified it with a 10 meg file which became a 14 meg >attachment. > Sendmail consumed an additional 5 megs combined while handling the input and output >v.s. > an idle daemon. Idle is 1.8M, recv was 4.0M, send was 2.3M, no measure on the remote > side. I sent it via pine to a remote address. As opposed to modern mail servers which can send messages of any size using constant sized small (well under 1M) processes. > - Requires high load average allowance > Incorrect. Same machine barely spiked a tenth of a point for this load and >dropped > back to .05. You saw load while sending a single file? Modern mail servers can send without generating significant load (unless your server was a 386). I've used older Pentium boxes that could send 60 messages at a time without hitting .1 load. Anyways, this is rather off topic for linux-kernel. -- Bruce Guenter <[EMAIL PROTECTED]> http://em.ca/~bruceg/ PGP signature
Patch to improve PCI consistency
Hi, The information about PCI devices is scattered about the kernel and, consequently, is inconsistent. This patch puts the PCI/IDE bridge information into a text database along with the data from include/linux/pci_ids.h and drivers/pci/pci.ids. I may have mis- typed a few things, but the 2.4.0-test11 kernel seems to compile and work for me. Below is the README from the patch and the patch lives here: ftp://autogen.linuxave.net/pub/PCIDEV.tgz This patch will unify the PCI device information between the PCI driver database (pci.ids), the PCI-IDE bridges (ide-pci.c) and the header that should enumerate all pci devices (pci_ids.h). It does this by putting all the data into a single file and tagging the values with names. These named values are then inserted into the output files. This will provide for guaranteed consistency, which is not now the case. In fact, there were some unresolvable inconsistencies in the data that are marked with ``FIXME'' comments. The patches are against linux-2.4.0-test11. There are other PCI device tables that could be generated as well. As it happens, though, I am only interested in PCI/IDE bridges. The rest are left as exercises for the reader. :-) Hand edited files: pci.def -- replacement for drivers/pci/pci.ids pci_ids.tpl -- Template for producing generated files :mkpcidev-- Script for constructing files (read before use!) PATCH-- a patch for the following files: drivers/pci/gen-devlist.c -- obsolete arch/i386/kernel/pci-irq.c drivers/char/serial.c drivers/pci/names.c drivers/pci/Makefile drivers/ide/ide-pci.c drivers/parport/parport_pc.c Generated files: drivers/pci/devlist.hreplacement for devlist.h and classlist.h drivers/ide/ide-pci.hReplacement for hand-coded tables in ide-pci.c include/linux/pci_ids.h replacement The patches mostly remove data that are now generated. However, some were changed because it is no longer possible to create #define-d values with mixed case (a lower case `x'). For the ide-pci.c file, however, it also renames macros that are inconsistent with the device names already defined in pci.ids (pci.def). = The tool that makes this all happen is: http://AutoGen.SourceForge.net/
Re: [PATCH] ide-pci.c: typo
Frédéric L . W . Meunier wrote: > > Alan Cox wrote: ... There are several typos, but it is not clear if they are all from ide-pci.c, or in the other files (pci.ids and pci_ids.h). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18 release notes
Peter Samuelson wrote: > > [AC] > > > ... added basic support for the Pentium IV. > [Android] > > How is the Pentium IV more advanced than the Pentium III, other than > > speed? Why would LInux care about a 1500 MHz clock or 400 MHz bus > > speed? Just treat the PIV as a faster PIII. > > It all sounds so simple, right? Several small things to worry about: > - maybe they'll need to patch lm_sensors to accommodate the increased > temperature range since the P4 runs so hot. (: (: Did someone go through the kernel and fix spin/wait's & spin/halt's with new magic instructions? I remember Intel itself was working on it, but I do not know if it was 2.4 only or 2.2 + 2.4. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 2.2.18 PCI_DEVICE_ID_OXSEMI_16PCI954
Lukasz Trabinski wrote: > include/linux/pci_ids.h:#define PCI_DEVICE_ID_OXSEMI_16PCI954 0x9501 > > (IMHO that is correct), but in kernel 2.2.18 we have: > (include/kernel/pci.h) > #define PCI_DEVICE_ID_OXSEMI_16PCI954PP0x9513 > ^^ > > Please correct, if I'm wrong, but IMHO it shuld be: > (include/kernel/pci.h) > #define PCI_DEVICE_ID_OXSEMI_16PCI954 0x9513 Please correct me if *I* am wrong, but shouldn't the names be different if the values are different? Also, excuse me while I soap-box for a moment: This and other inconsistencies would be easier to deal with if there were a single repository for PCI information from which all the PCI device tables and ID enumerations were derived. I have posted the technology that can easily be adapted to emit both 2.2 and 2.4 flavors of tables, though only PCI-IDE stuff for 2.4 is currently implemented. See ftp://autogen.linuxave.net/pub/PCIDEV.tgz Tiny drawback: you must download and use this to generate all the output tables: ftp://autogen.linuxave.net/pub/autogen-5.1.3.tar.gz Homepage (with broken download link due to SourceForge outage): http://AutoGen.SourceForge.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Unknown PCI device?
"Mike A. Harris" wrote: > >> Anyone know what this is? > >> > >> 00:07.3 Host bridge: VIA Technologies, Inc.: Unknown device 3050 (rev 30) > >> Flags: medium devsel > > > >if its pci id is 0x11063050, then it's a VIA Power Management Controller. > > 00:07.3 Class 0600: 1106:3050 (rev 30) > Flags: medium devsel > > Yip. Someone might want to update the PCI ID db, or whatever > with that.. If this were to be adopted: ftp://autogen.linuxave.net/pub/PCIDEV.tgz I would finish it so that there would be one and only one place to update for any and all PCI devices for 2.2, 2.4 and any other kernel. However, it would take several days and I won't do it unless there were some reasonable chance for adoption. The referenced implementation only covers the 2.4 kernel: 1. the list of PCI manufacturers and devices 2. the IDE controllers still to do would be the dispatch tables for other kinds of devices, the tables for the 2.2 kernel and the device information for the non-IDE dispatch tables. (The latter being the hard [time consuming] part. Creating the tables from the data is easy.) Once this is all done, both the 2.2 and 2.4 (and future) kernels would be kept up to date by updating a single database and regenerating the tables. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
Hi. Do you get messages like the ones below in /var/log/messages? sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs sym53c875-0-<0,0>: tagged command queue depth set to 7 In fact, do you get any messages in your log files that look like they might be related? -- Bruce Harada [EMAIL PROTECTED] On Sun, 28 Jan 2001 02:26:32 -0500 "paradox3" <[EMAIL PROTECTED]> wrote: > I have an SMP machine (dual PII 400s) running 2.2.16 with one 10,000 RPM > IBM > 10 GB SCSI drive > (AIC 7890 on motherboard, using aic7xxx.o), and four various IDE drives. > The > SCSI drive > performs the worst. In tests of writing 100 MB and sync'ing, one of my > IDE > drives takes 31 seconds. The SCSI drive (while doing nothing else) took > 2 minutes, 10 seconds. This is extremely noticable in file transfers > that > completely > monopolize the SCSI drive, and are much slower than when involving the > IDE > drives. > After a large data operation on the SCSI drive, the system will hang for > several minutes. > Anyone know what could be causing this? Thanks. > > Attached are some data to help. > > > Thanks, > Para-dox ([EMAIL PROTECTED]) > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Poor SCSI drive performance on SMP machine, 2.2.16
Hm. As a point of comparison, I use a similar system to yours (full SCSI, though, no IDE) and I can copy a 100MB file from disk-to-disk, or on the same disk, in around 13 seconds. Where are you copying to the SCSI drive from - the same drive, an IDE disk, CDROM? If IDE, what are its particulars? (Check with hdparm -iI /dev/hd?) -- Bruce Harada [EMAIL PROTECTED] On Sun, 28 Jan 2001 12:44:29 -0500 "paradox3" <[EMAIL PROTECTED]> wrote: > > I don't get any messages relating to the drives in any syslog output. > > > > > Do you get messages like the ones below in /var/log/messages? > > > > sym53c875-0-<0,0>: QUEUE FULL! 8 busy, 7 disconnected CCBs > > sym53c875-0-<0,0>: tagged command queue depth set to 7 > > > > In fact, do you get any messages in your log files that look like they > > might be related? > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: rlim_t and DNS?
On Thu, 1 Feb 2001 09:53:35 -0500 (EST) Admin Mailing Lists <[EMAIL PROTECTED]> wrote: > > Trying to compile bind 9.1.0 here. > Kernel is 2.2.18, gcc 2.7.2.1. > It failed trying to find the type for rlim_t. > The C file says BSD/OS is the only OS they found not to have rlim_t. > Am I missing something? > Where can i find this in linux? I looked in all the include > files, including resource.h Are you sure you looked in ALL the include files? I seem to have it as: /usr/include/bits/resource.h:typedef __rlim_t rlim_t; where __rlim_t is /usr/include/bits/types.h:typedef long int __rlim_t; so you could try including those two in the appropriate places. > For now i jsut typedefed it as a long. > > Also, it's looking for a setting for SYS_capset to pass to syscall() > and can't that either. Again, I looked in the include files without > success. I have this: /usr/include/bits/syscall.h:#define SYS_capset __NR_capset Hope that helps (although l-k probably isn't the best place for this...) -- Bruce Harada [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lkml subject line
On Mon, 12 Feb 2001 10:25:47 -0500 (EST) Mike Harrold <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] said: > > The advantages can all be gained without that disadvantage by just > learning > > to filter mail on other headers instead of the subject line. > > Assuming your mail reader can do that (and no, I can't change my mail > reader). Use procmail, that's what it's there for (and it won't affect your mail reader, as long as you're using something reasonably sensible). I filter on Sender. -- Bruce Harada [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://vger.kernel.org/lkml/
Re: lkml subject line
On Mon, 12 Feb 2001 11:56:00 -0500 (EST) Mike Harrold <[EMAIL PROTECTED]> wrote: > > Use procmail, that's what it's there for (and it won't affect your > > mail > > reader, as long as you're using something reasonably sensible). I > > filter on Sender. > > Maybe I don't *want* the LKML messages in a seperate folder. > Maybe I just want to identify them at a pinch in my inbox? > Maybe my employer doesn't allow me to install additional software > anyway? So in other words, because you like to have all your incoming mail in one big pile, and your boss is inflexible, everybody else on l-k has to do as you say? Hm Anyway, I think we've cluttered the list enough for today. -- Bruce Harada [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://vger.kernel.org/lkml/
Re: Is this the ultimate stack-smash fix?
On Tue, 13 Feb 2001 21:22:26 + (GMT) James Sutherland <[EMAIL PROTECTED]> wrote: > On Tue, 13 Feb 2001, Jeremy Jackson wrote: > > (Long description of how to create a non-executable stack on x86) > > ISTR there is a patch which does this for Linux, though?? See: http://www.openwall.com/linux/ for Solar Designer's patch, and: http://www.insecure.org/sploits/non-executable.stack.problems.html for the exploit. It was done to death on the linux-security ML a while ago, so you could search the archives if you want to know more. -- Bruce Harada [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: Maintainers master list?
>I have proposed that the MAINTAINERS file should be replaced by >metadata markup in the kernel sources themselves, distributed so that >it will naturally be kept up to date by the people named in it and >mechanically gathered into a generated MAINTAINERS at make dep time. >I still think this is the right thing, and was planning to revisit the >issue after the 2.5 cutover. But it certainly doesn't have to be me that >does it, and between CML2 and the Configure.help file and countering >Microsoft's anti-open-source propaganda war I have plenty of other things >to worry about. >So if you want to take this on, I encourage you to go to it. Want a >copy of the metadata schema I wrote up? I would be happy to look at any work that you have already done on this, so feel free to send it along to me. Let's take a look at what you have and where we might be able to take this. B. - 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/
Will Riel's vmpatch make it into 2.4.0-test9?
Hello... Just a question from a user... :) I was just wondering if Rik van Riel's VM patches might possibly be integrated into 2.4.0-testX anytime soon? I have been having very good experiences with Riel's latest patches in both a desktop and light server environment. On the desktop, Riel's vmpatch against 2.4.0-test8 is significantly better then 2.4.0-test8's performance. Operation seems much faster and smoother. In fact, I'd say it could even be much better then whats floating around in 2.2.x now! Just a couple of examples on where the differences in Riel's patches become apparent (though one might argue that they are useless indicators) I have recently been having difficulty with Loki Games's latest patches for the game Unreal Tournament. The problem is it leaks memory very quickly. After about two minutes of gameplay the process takes up 300+MB of memory with an increase of around 10mb per minute. This machine only has 256mb of ram so you can imagine that it starts to swap at that point. Usually under 2.2.x it takes about 4 minutes of gameplay before I hear my harddrive screetch and the game starts becoming unresponsive. With Riel's patch and 2.4.0-test8, I can sometimes play for up to 6 minutes before the swapping makes the game unusual. Is Riel's patch more efficient at swapping or something? Another example... Start Quake3, join a game on the internet and play for about 5 minutes. Then quit and go right back into the game. With Riel's patch the harddrive is only touched for a brief second. With 2.2.x the harddrive is touched for a few seconds while quake3 loads the maps, etc that were played before. Riel's patch seems to keep things cached in memory much more efficiently. And yet another example... mkisofs on my system is a dog with 2.4.0-test8. It kills performance of other applications and makes mp3 players skip etc. There is no skipping and "freezeups" with Riel's patch. Although mkisofs seems slower under 2.4.0-test8+vmpatch then stock 2.2.x, Riel's VM seems to be much "smoother". I tried Riel's patch on a lightly loaded webserver. Though because of the lack of any substantial load on the system I don't think its worth commenting on it... Perhaps other people could comment on their experiences? I am looking forward to vmpatch with the planned IO tweaks and out of memory handler... I would hate to have to patch the VM system throughout the 2.4.x stable tree with his patch so I'm lobbying for it to be included. :) Just my opinions and experiences... please feel free to flame away if I am misunderstanding something... Thanks for your time. -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
PERCRAID 3 drivers?
Hello... The organization I do some work for purchased a rackmount server from Dell with the intent of running some webconferencing software under Linux. The salesman we had spoken to assured us that Linux fully supported the machine. Yeah... Right... :) Now it seems I'm stuck with a PERCRAID 3 card that only has support in the form of a binary kernel module for kernel 2.2.14 (w/ redhat's patches). While the box runs fine with this kernel, I would definatly like to upgrade the kernel to something that doesn't have so many known flaws ;) The machine is already in use so switching raid cards isn't much of an option at this time. A check of Dell's (rather horrible) support website only turns up the binary module mentioned above. Does anyone know anything about these PERCRAID 3 cards and if there is an opensource driver? or at least a binary module for a newer kernel? Thanks for your time... ------ Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PERCRAID 3 drivers?
So does this mean that the driver currently in redhat's pinstripe beta should be avoided on an production SMP system? Is sticking with 2.2.14 perferable right now? Anyone know how far along the adaptec guys are? Thanks for your time... On Sun, 17 Sep 2000, Alan Cox wrote: > > AFAIK, Dell wrote these drivers themselfs and they are unwilling to release > > The drivers for the percraid have adaptec copyrights and have been made > available finally but were too ugly at the moment to merge (and had some > obvious potentially nasty bugs like using down() on a spinlock > > The adaptec guys are cleaning it up > ------ Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PERCRAID 3 drivers?
As a matter of fact I already have such a kernel compiled but I need to be
there in person to make sure it doesn't blow up. :)
There were four files:
linux-2.2.16-aacraid-1.0.3.patch
linux-2.2.16-aacraid-1.0.3-paths.patch
linux-2.2.16-aacraid-1.0.4.patch
linux-2.2.16-aacraid-1.0.5.patch
The only part of the patchs that caused a reject with 2.2.17 was this:
--- linux/drivers/scsi/scsi.c.aacraid Tue Jun 13 12:52:09 2000
+++ linux/drivers/scsi/scsi.c Tue Jun 13 12:52:42 2000
@@ -307,6 +307,8 @@
{"MATSHITA","PD-1","*", BLIST_FORCELUN | BLIST_SINGLELUN},
{"iomega","jaz 1GB","J.86", BLIST_NOTQ | BLIST_NOLUN},
{"TOSHIBA","CDROM","*", BLIST_ISROM},
+{"DELL", "PERCRAID", "*", BLIST_FORCELUN},
+{"HP", "NetRAID-4M", "*", BLIST_FORCELUN},
{"MegaRAID", "LD", "*", BLIST_FORCELUN},
/*
* Must be at end of list...
Easily addable by hand.
Though I am concerned about the KNOWNBUGS file that was in the 1.0.3 patch
but was removed by the later version patches. It seems to indicate its a
bad idea to compile it directly in the kernel. Is it better to compile it
as a module?
Thanks for your time...
On Mon, 18 Sep 2000, Jon Mitchell wrote:
> On Sun, Sep 17, 2000 at 09:40:18AM -0500, [EMAIL PROTECTED] wrote:
> > The aacraid driver was submitted to Alan Cox, but rejected because it has
> > too many "NTism's" in it, which are being addressed. Please see the Red Hat
> > Linux "Pinstripe" beta kernel source RPM for the source code, or contact me
> > privately.
>
> Or, you can get this yourself. Evidently the source code is released.
>
> By going to Dell's website and downloading the kernel source rpm for
> 2.2.16-3, then installing the kernel rpm with rpm -i. Finally go into the
> /usr/src/redhat/SOURCES directory and you will find two files with aacraid
> in the name. These patches will apply (patch is able to make due with the
> slight line number changes) with only a couple of exceptions. You will
> find the rejects extremely easy to fix because 3 out of 4 of them are
> already in the kernel, only one thing actually needs to be fixed by hand.
>
> Then make config and say yes to adaptec raid controller question. Just
> had to do this last week, and if necessary I can make a patch and send it
> out that applies correctly to the 2.2.18pre series.
>
> --
> Jon Mitchell
> Systems Engineer, Subject Wills & Company
> [EMAIL PROTECTED]
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Bruce A. Locke
[EMAIL PROTECTED]
"The Internet views censorship as damage and routes around it"
www.eff.org www.peacefire.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
RE: PERCRAID 3 drivers?
Thanks to everyone who responded. The aacard driver patches that were in the Redhat pinstripe kernel SRPM work fine with 2.2.17. The machine seems pretty stable and speed is about the same as with the binary driver. Thanks again... -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
Hi again. The latter half of my email seems to have been forgotten in the ensuing discussion, so I'll repost. For a linked list of any non-floating point data, radix sort is almost impossible to beat; it's iterative, fast (linear time for fixed size integers, worst case), can be stopped early for partial sorting, and has a pretty simple implementation. I've been using essentially the same radix sort implementation I posted before to sort 1000 item lists 60 times a second in a numerical application, and it barely shows up in the total time used when profiling. The other sorts I tried did not fare so well. I would much rather see this in a kernel modification than any merge/quick/heap sort implementations I've seen so far for linked lists. OTOH, this conversation seems to have wandered out of kernel-space anyway... - Jim Bruce (Examples at: http://www.cs.cmu.edu/~jbruce/sort.cc) 10-Mar-2001 Re: quicksort for linked list by David [EMAIL PROTECTED] > For modern machines, I'm not sure that quicksort on a linked list is > typically much cheaper than mergesort on a linked list. The > majority of the potential cost is likely to be in the pointer > chasing involved in bringing the lists into cache, and that will be > the same for both. Once the list is in cache, how much pointer > fiddling you do isn't so important. For lists that don't fit into > cache, the advantages of mergesort should become even greater if the > literature on tape and disk sorts applies (though multiway merges > rather than simple binary merges would be needed to minimize the > impact of memory latency). > > Given this, mergesort might be generally preferable to quicksort for > linked lists. But I haven't investigated this idea thoroughly. > (The trick described above for avoiding an explicit stack also works > for mergesort.) - 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: quicksort for linked list
Quicksort works just fine on a linked list, as long as you broaden
your view beyond the common array-based implementations. See
"http://www.cs.cmu.edu/~jbruce/sort.cc" for an example, although I
would recommend using a radix sort for linked lists in most situations
(sorry for the C++, but it was handy...).
9-Mar-2001 Re: quicksort for linked list by Helge [EMAIL PROTECTED]
> Manoj Sontakke wrote:
> >
> > Hi
> > Sorry, these questions do not belog here but i could not find any
> > better place.
> >
> > 1. Is quicksort on doubly linked list is implemented anywhere? I need it
> > for sk_buff queues.
>
> I cannot see how the quicksort algorithm could work on a doubly
> linked list, as it relies on being able to look
> up elements directly as in an array.
>
> You can probably find algorithms for sorting a linked list, but
> it won't be quicksort.
It's quicksort as long as you do pivot/split, the array gymnastics
that most implementations do to avoid updating array elements isn't
really critical to its operation.
> 1. find out how many elements there are. (Count them if necessary)
> 2. Allocate a pointer array of this size.
> 3. fill the pointer array with pointers to list members.
> 4. quicksort the pointer array
> 5. Traverse the pointer array and set the links for each
>list member to point to next/previous element pointed
>to by the array. Now you have a sorted linked list!
I think a radix sort like the following would work better with about
the same (or less) storage, provided you're comparing ints (this is
for a kernel modification after all, right?). You just need to
determine the number of passes to cover all the bits in the numbers
you want to sort.
- Jim Bruce
#define RADIX_BITS 6
#define RADIX (1 << RADIX_BITS)
#define RADIX_MASK (RADIX - 1)
struct item *radix_sort(struct item *list,int passes)
// Sort list, largest first
{
struct item *tbl[RADIX],*p,*pn;
int slot,shift;
int i,j;
// Handle trivial cases
if(!list || !list->next) return(list);
// Initialize table
for(j=0; jnext;
slot = ((p->key) >> shift) & RADIX_MASK;
p->next = tbl[slot];
tbl[slot] = p;
p = pn;
}
// integrate back into partially ordered list
list = NULL;
for(j=0; jnext;
p->next = list;
list = p;
p = pn;
}
}
}
// fix prev pointers in list
list->prev = NULL;
p = list;
while(pn = p->next){
pn->prev = p;
p = pn;
}
return(list);
}
-
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] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 &OOM handler)
Your making the deadly assumption that all applications behave themselves exactly the same all the time. Oops... netscape decided to freak out and take up all your memory... guess its the admins fault. Oops... some mod_perl script decided to freak out and an apache process decides to suck all of your CPU and MEM. Crap like this does happen. An example of this is a webboard package called "Blackboard" consisting of various mod_perl scripts, apache, and mysql. It is an educational online conferencing system being used in conjunction with many college classes and thus is quite vital to the campus. Unfortunatly its buggy as hell and the memory sucking bug didn't pop up until we were a couple weeks into classes and locked into the system. A mod_perl script freaks out, the copy of apache goes nuts, and we get a bunch of lovely out of memory related messages to the console. Its times like these that an OOM killer like Rik's would be very useful. I feel Rik's OOM backported to 2.2.x would do wonders for situation. After playing with Rik's OOM system, I know it would do the right thing on this system but unfortunatly 2.4.x isn't trustworthy yet Yes, the software is buggy and should be fixed. Do I have the power to fix a broken commerical package that I'm locked into? No. The point of an OOM killer is if all hell breaks loose and you have a choice between a locked up system, a system thats slow as hell because its spending all its time swapping, or a system that kills the offender and gets back to buisness. I choose the third option. I can't think of any situation (either on desktop or server) where a system lockup or panic due to OOM would be acceptible w/ 2.4.x. On Thu, 12 Oct 2000, Matthew Hawkins wrote: > > Heh.. now all we need is some smart-arse to make something similar to > apply to the _entire_ VM subsystem, and both Rik and Andrea can be happy > ;) > > Seriously, am I missing something obvious or is it far simpler just to > keel over and die if the system goes OOM? I mean, seriously, if the > administrator lets it get to that state then he/she/it deserves a dead > system. It's akin to having your car run out of petrol - you don't > start shooting passengers because their extra load made the engine chew > more. You pack up your kitty and go to the nearest petrol station and > buy more, plug it into the car then learn from the experience so this > fringe case of it happening doesn't happen again. I don't really see > much difference between a car going "OOP" and a computer going OOM. > Should we start deleting files according to some randomly-chosen > heueristic if a filesystem goes "OOS" ? > > -- > Matt > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 &OOM handler)
On Thu, 12 Oct 2000, Matthew Hawkins wrote: > Yep, for not setting appropriate resource limits. > > man 2 setrlimit > > Of course, if its a kernel bug that causes it I think you're SOL ;) This manpage shows me functions and structs. I'm assuming you want these used by the offending program or the shell under which the program is being called. In the first case, a person might not have source to the program and if thats the case, it doesn't help much. And in the second case, if the shell sets it, does it affect children of a process (aka fork()'d)? Thanks for yout time... > > -- > Matt > -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 &OOM handler)
On Wed, 11 Oct 2000, Paul Jakma wrote: > that's why you have per process limits set. Eg, PAM makes this > exceedingly easy with pam_limit.so -> edit /etc/security/limit.conf. > > this prevents at least 90% of OOM situations (ie individual leaky > processes). eg netscape will then pop-up "can not allocate memory" > messages and stop rendering pages instead of crashing your system. I wasn't aware PAM settings affected daemons started up during boottime but I will check into it, thank you. BTW, you said it works only 90%, what are the other 10% of times it doesn't work? > > --paulj > -- Bruce A. Locke [EMAIL PROTECTED] "The Internet views censorship as damage and routes around it" www.eff.org www.peacefire.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
