ftruncate not extending files?
On Thu, Mar 01, 2001 at 06:19:35PM +, Alan Cox wrote: > > In that case, why was it changed for FAT only? Ext2 will still > > happily enlarge a file by truncating it. > > ftruncate() and truncate() may extend a file but they are not required to > do so. Stevens' example code assumes that it does. And given the number of people that regard his work as Holy, it might not be a bad idea to implement Linux so that it does what people think it does. I would've sworn, based on the fact that I saw people do it, that ftruncate was a legitimate way to extend a file - especially useful in combination with mmap(). I don't really care where it is done, in glibc or in the kernel - but let's honor this convention and not needlessly break code. Regards, bert hubert -- 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: 2.4.2ac8 lost char devices
Hi, I lost graphics on my i810 - failed to get minor is the error message on boot. Ashwin - 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.2ac8 lost char devices
Hello,
At Fri, 02 Mar 2001 00:42:28 -0500,
<[EMAIL PROTECTED]> wrote:
>
> actually, its not just ps/2 mice -- it seems to be something generic to char
> devices. agpgartis failing to register itself, too.
>
> what changed with char device handling from ac7 to ac8?
>
> robert love
> [EMAIL PROTECTED]
> -
misc_register() in drivers/char/misc.c seems to have a problem.
int misc_register(struct miscdevice * misc)
{
static devfs_handle_t devfs_handle;
-
+ struct miscdevice *c;
+
if (misc->next || misc->prev)
return -EBUSY;
down(&misc_sem);
+ c = misc_list.next;
+
+ while ((c != &misc_list) && (c->minor != misc->minor))
+ c = c->next;
+ if (c == &misc_list) {
This should be (c != &misc_list)
+ up(&misc_sem);
+ return -EBUSY;
+ }
---
Nobuhiro Tachino
Development Department
Linux Division
Software Group
FUJITSU LIMITED
TEL: +81 559 24 7273
FAX: +81 559 24 6196
E-Mail: [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.2ac8 lost char devices
actually, its not just ps/2 mice -- it seems to be something generic to char devices. agpgartis failing to register itself, too. what changed with char device handling from ac7 to ac8? robert love [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.2 sound [ad1848] eating cpu?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This may be a bit off topic, and if it is, please point me in the right direction. I have a Dell Inspiron 3500 (Cel 333a/196mb w/ the NeoMagic256AV chipset), which I've had running 2.2.14 & 2.2.16 for some time, with flawless performance. I recently upgraded to 2.4.2 (and made sure to go through the Changes.txt file to catch all the utilities, so they're all up to date), and used the same configureation optiosn for sound support as I had before in 2.2 (basically building the necessary drivers as modules again). However, with 2.4.2, whenever I try to play any sound file, be it a .wav or .mp3, I now have what sounds like static intermittently in the playback, coinciding with large cpu usage (up to 100%). These static "bursts" are of varying length, but become worse if there is any other activity on the system. Sometimes the whole machine will freeze as the sound system is outputting static, and then seems to pulse: a little pop from the speakers, and an instant of system responsiveness followed by a few more seconds of freeze. I'm running vanilla 2.4.2 sources + the 2000-02-15 snapshot of FreeS/WAN. This problem was present before I patched FreeS/WAN in, and I can switch back to a kernel without ipsec if needed for testing. some (what I hope is) relevant information: root@gopher(pts/2):/ 139 # lsmod Module Size Used by mpu401 18704 0 (unused) ad1848 16736 0 sound 55920 0 [mpu401 ad1848] soundcore 3920 4 [sound] serial_cs 5744 0 (unused) usb-uhci 21744 0 (unused) 3c575_cb 20352 2 cb_enabler 2864 2 [3c575_cb] ds 6960 2 [serial_cs cb_enabler] i82365 24208 2 pcmcia_core44960 0 [serial_cs cb_enabler ds i82365] serial 42576 0 (autoclean) [serial_cs] usbcore46576 1 (autoclean) [usb-uhci] root@gopher(pts/2):/ 140 # cat /proc/dma 0: MS Sound System 1: MS Sound System 4: cascade root@gopher(pts/2):/ 141 # cat /proc/interrupts CPU0 0: 314837 XT-PIC timer 1:277 XT-PIC keyboard 2: 0 XT-PIC cascade 3: 76748 XT-PIC eth0 5: 2483 XT-PIC MS Sound System 8: 1 XT-PIC rtc 11: 0 XT-PIC usb-uhci 12: 2520 XT-PIC PS/2 Mouse 14: 224597 XT-PIC ide0 15: 4 XT-PIC ide1 NMI: 0 ERR: 2 root@gopher(pts/2):/ 142 # 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 0280-02ff : cb_enabler 0376-0376 : ide1 03c0-03df : vga+ 03e8-03ef : serial(set) 03f6-03f6 : ide0 03f8-03ff : serial(auto) 0530-0533 : WSS config 0534-0537 : MS Sound System 0cf8-0cff : PCI conf1 2180-219f : Intel Corporation 82371AB PIIX4 ACPI 8000-803f : Intel Corporation 82371AB PIIX4 ACPI fcd0-fcdf : Intel Corporation 82371AB PIIX4 IDE fce0-fcff : Intel Corporation 82371AB PIIX4 USB fce0-fcff : usb-uhci root@gopher(pts/2):/ 143 # I'm really at a loss as to what might be wrong... all the hardware settings look to be the same as when I was running 2.2. In case anyone's wondering why I'm running the NeoMagic256AV chipset in Ad-Lib emulation, it's because it worked =), and because several other websites of people who run this same type of laptop said they were able to get sound working. I've tried the 2.2.x NM256 drivers, and they only ended up locking the machine quite hard, so I haven't wanted to try them in 2.4.2 yet. Again, if anyone knows where would be a better place for me to look for help, please tell me. Thanks. - -- Gregory K. Ade <[EMAIL PROTECTED]> | <[EMAIL PROTECTED]> http://bigbrother.net/~gkade GPG ID/FP: EAF4844B | F4FCCC7D613DBDBF5365 E3D079050460EAF4844B -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE6nzEUeQUEYOr0hEsRAhj3AJ9y7JQIeAS4dgGN5t0V+oJHa6XtqQCg0UYa fuHXrwQWJLULGWtoxXAoqqY= =yQW/ -END PGP SIGNATURE- - 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/
strange nonmonotonic behavior of gettimeoftheday
I've got following problem with 2.2.17 (Redhat stock kernel)
Linux * 2.2.17-14 #1 Mon Feb 5 14:57:25 EST 2001 i586 unknown
on AMD K6, VIA Technologies VT 82C586, Compaq Presario XL119.
Following C program
#include
#include
#include
#include
#define ABS(x) (x < 0 ? -x : x)
#define TIME_T struct timeval
#define TIME_DIFF_T long
#define GET_TIME(x) gettimeofday(&x, NULL)
#define TIME_DIFF(x1, x2) ((x2.tv_sec - x1.tv_sec)*100 + (x2.tv_usec -
x1.tv_usec))
int main(int argc, char** argv)
{
TIME_T t1, t2;
TIME_DIFF_T d;
GET_TIME(t2);
while (1) {
GET_TIME(t1);
d = TIME_DIFF(t2, t1);
if (d > 50 || d < 0) {
fprintf(stderr, "Leap found: %ld msec\n", d);
return 0;
}
t2 = t1;
}
return 1;
gives following result on box in question
root@**:# ./clo
Leap found: -1687 msec
and prints nothing on all other my boxes.
This gives me bunch of troubles with occasional hang ups and I found nothing
in kernel archives at
http://www.uwsg.indiana.edu/hypermail/linux/kernel/index.html
just some notes about smth like this for SMP boxes with ntp. Is this issue
known, and how can I fix it?
Thanks.
_
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: [patch][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Rik van Riel wrote: > > > The merging at the elevator level only works if the requests sent to > > > it are right next to each other on disk. This means that randomly > > > sending stuff to disk really DOES DESTROY PERFORMANCE and there's > > > nothing the elevator could ever hope to do about that. > > > > True to some (very real) extent because of the limited buffering > > of requests. However, I can not find any useful information > > that the vm is using to guarantee the IT does not destroy > > performance by your own definition. > > Indeed. IMHO we should fix this by putting explicit IO > clustering in the ->writepage() functions. I notice there's a patch sitting in my mailbox.. think I'll go read it and think (grunt grunt;) about this issue some more. Thanks for the input Rik. I appreciate it. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What is 2.4 Linux networking performance like compared to BSD?
Alan Cox wrote: > The extreme answer to the 2.4 networking performance is the tux specweb > benchmarks but they dont answer for all cases clearly. However, I think you've hit the nail on the head here; much of tux is just general-purpose network file-blasting. The right hacker could turn it into the fastest web-cache on the planet with the right modules. I believe Ingo already did a basic ftp server based on tux, just to demonstrate this generality. Ingo? Am I crazy or enlightened? regards, David - 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][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Chris Evans wrote: > Oh dear.. not more "vm design by waving hands in the air". Come on people, > improve the vm by careful profiling, tweaking and benching, not by > throwing random patches in that seem cool in theory. Excuse me.. we're trying to have a _constructive_ conversation here. -Mike - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.2 + SMP + EMU10k1 == lock?
Hello, I asked here about a week ago for help with debugging a random lock I've been experiencing. With the help of Mr. Owens, I seem to have gotten a bit further. (Long winded way of saying, "Sorry about the messy looking, clueless debugging.") I'm running 2.4.2 + KDB 1.8 on my SMP machine (2xp3-600). I have a serial console connected to my box. It looks like things might be locking up in the EMU10k1 driver. Anyone else? Is there any further info I can provide to someone who might be working on this? Thanks, pete [0]kdb> rd eax = 0xc983cca0 ebx = 0x ecx = 0xc02c8794 edx = 0x esi = 0x3296 edi = 0x esp = 0xc028bf34 eip = 0xe08ac8bd ebp = 0xc028bf40 xss = 0x0018 xcs = 0x0010 eflags = 0x00013096 xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc028bf00 [0]kdb> bt EBP EIP Function(args) 0xc028bf40 0xe08ac8bd [emu10k1]emu10k1_waveout_bh+0x11 (0xc983cca0, 0x1, 0xc02c7680) emu10k1 .text 0xe08aa060 0xe08ac8ac 0xe08ac950 0xc028bf58 0xc011bd6b tasklet_hi_action+0x4f (0xc02c7680, 0x0, 0xc02be800) kernel .text 0xc010 0xc011bd1c 0xc011bda4 0xc028bf78 0xc011bbfd do_softirq+0x5d (0xc01071d0, 0xc028a000) kernel .text 0xc010 0xc011bba0 0xc011bc30 0xc028bf94 0xc010b09e do_IRQ+0xda (0xc01071d0, 0x0, 0xc028a000, 0xc028a000, 0xc01071d0) kernel .text 0xc010 0xc010afc4 0xc010b0b0 0xc010919c ret_from_intr kernel .text 0xc010 0xc010919c 0xc01091bc Interrupt registers: eax = 0x ebx = 0xc01071d0 ecx = 0x edx = 0xc028a000 esi = 0xc028a000 edi = 0xc01071d0 esp = 0xc028bfd0 eip = 0xc01071ff ebp = 0xc028bfd0 xss = 0x0018 xcs = 0x0010 eflags = 0x3246 xds = 0xc0100018 xes = 0xc0280018 origeax = 0xff00 ®s = 0xc028bf9c 0xc01071ff default_idle+0x2f kernel .text 0xc010 0xc01071d0 0xc0107208 0xc028bfe4 0xc0107272 cpu_idle+0x42 kernel .text 0xc010 0xc0107230 0xc0107288 [0]kdb> rd eax = 0xc983cca0 ebx = 0x ecx = 0xc02c8794 edx = 0x esi = 0x3296 edi = 0x esp = 0xc028bf34 eip = 0xe08ac8bd ebp = 0xc028bf40 xss = 0x0018 xcs = 0x0010 eflags = 0x00013096 xds = 0x0018 xes = 0x0018 origeax = 0x ®s = 0xc028bf00 [0]kdb> bt EBP EIP Function(args) 0xc028bf40 0xe08ac8bd [emu10k1]emu10k1_waveout_bh+0x11 (0xc983cca0, 0x1, 0xc02c7680) emu10k1 .text 0xe08aa060 0xe08ac8ac 0xe08ac950 0xc028bf58 0xc011bd6b tasklet_hi_action+0x4f (0xc02c7680, 0x0, 0xc02be800) kernel .text 0xc010 0xc011bd1c 0xc011bda4 0xc028bf78 0xc011bbfd do_softirq+0x5d (0xc01071d0, 0xc028a000) kernel .text 0xc010 0xc011bba0 0xc011bc30 0xc028bf94 0xc010b09e do_IRQ+0xda (0xc01071d0, 0x0, 0xc028a000, 0xc028a000, 0xc01071d0) kernel .text 0xc010 0xc010afc4 0xc010b0b0 0xc010919c ret_from_intr kernel .text 0xc010 0xc010919c 0xc01091bc Interrupt registers: eax = 0x ebx = 0xc01071d0 ecx = 0x edx = 0xc028a000 esi = 0xc028a000 edi = 0xc01071d0 esp = 0xc028bfd0 eip = 0xc01071ff ebp = 0xc028bfd0 xss = 0x0018 xcs = 0x0010 eflags = 0x3246 xds = 0xc0100018 xes = 0xc0280018 origeax = 0xff00 ®s = 0xc028bf9c 0xc01071ff default_idle+0x2f kernel .text 0xc010 0xc01071d0 0xc0107208 0xc028bfe4 0xc0107272 cpu_idle+0x42 kernel .text 0xc010 0xc0107230 0xc0107288 [0]kdb> bt EBP EIP Function(args) 0xc028bf40 0xe08ac8bd [emu10k1]emu10k1_waveout_bh+0x11 (0xc983cca0, 0x1, 0xc02c7680) emu10k1 .text 0xe08aa060 0xe08ac8ac 0xe08ac950 0xc028bf58 0xc011bd6b tasklet_hi_action+0x4f (0xc02c7680, 0x0, 0xc02be800) kernel .text 0xc010 0xc011bd1c 0xc011bda4 0xc028bf78 0xc011bbfd do_softirq+0x5d (0xc01071d0, 0xc028a000) kernel .text 0xc010 0xc011bba0 0xc011bc30 0xc028bf94 0xc010b09e do_IRQ+0xda (0xc01071d0, 0x0, 0xc028a000, 0xc028a000, 0xc01071d0) kernel .text 0xc010 0xc010afc4 0xc010b0b0 0xc010919c ret_from_intr kernel .text 0xc010 0xc010919c 0xc01091bc Interrupt registers: eax = 0x ebx = 0xc01071d0 ecx = 0x edx = 0xc028a000 esi = 0xc028a000 edi = 0xc01071d0 esp = 0xc028bfd0 eip = 0xc01071ff ebp = 0xc028bfd0 xss = 0x0018 xcs = 0x0010 eflags = 0x3246 xds = 0xc0100018 xes = 0xc0280018 origeax = 0xff00 ®s = 0xc028bf9c 0xc01071ff default_idle+0x2f kernel .text 0xc010 0xc01071d0 0xc0107208 0xc028bfe4 0xc0107272 cpu_idle+0x42
Re: [RFC] pci_set_dma_mask() + doc :)
Zach Brown writes: > please feel free to flame or apply, I'm not sure I'm really fond of the > code example.. Seems fine to me. 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: [Newbie] Re: Problem creating filesystem
Rogerio Brito wrote: > On Feb 26 2001, Jeremy Jackson wrote: > > Carlos Fernandez Sanz wrote: > > > The IDE controller is > > > Bus 0, device 17, function 0: > > > Unknown mass storage controller: Promise Technology Unknown device (rev > > > 2). > > > Vendor id=105a. Device id=d30. > > > Medium devsel. IRQ 10. Master Capable. Latency=32. > > > > Unrelated to disk "problem", you might want to set your PCI latency timer in > > BIOS to 64 or more. This should be accessible in your BIOS setup. I'm basing my comments on one NIC driver complaining in my logs and overriding settings lower that 64; however the general idea is to trade off latency for throughput. If I go crazy, like 192 or so, on *my* system, sound card starts to pop a bit, indicating that it's fifo buffer is smaller that that and is emptying when other devices are using the bus at the same time (it's like a timeslice) > > > Ok, I understand that this is probably off-topic and way too > basic, but what exactly would this do, in layman terms? Would > the latency being set to 32 result in any potential data > corruption? BTW, to set this quantity, one should use setpci, > right? - 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.2ac8 lost char devices
Mark Hahn wrote: > > > > > > Well, somethig has broken in ac8, because I lost my PS/2 mouse and > > > > > me too . > > No luck. same here - > it seems to be the mdelay(2) added to pc_keyb.c in -ac6. -ac7 is fine here, but when I boot -ac8, there's no ps/2 mouse. 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/
INFO NEEDED
hi One of my friend needs some information on third party products on LINUX 1)Are there any RDBMS available on linux 2)IF they are present ,then how powerful are they (relatively) 3)Are there any Databases which come along with the LINUX open source. I will be thankful for ur kind feedback on these questions. With regards, Girish.S. fac-K phone: 5578300 ext:1211 - 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.x very unstable on 8-way IBM 8500R
On Thu, 1 Mar 2001, Dr. Kelsey Hudson wrote: >> I've been playing around with 8-way IBM8500R (8x700MHz Xeon) with 4.5GB >> memory & AIC7xxx SCSI-controller. It's perfectly stable with 2.2-kernel >> (from Red Hat 7) but very erratic on all 2.4-kernels I've tried it with >> (2.4.[012], compiled both with egcs and RH7's gcc-2.96, both share the > >Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is >inherently broken(*). http://www.bero.org/gcc296.html >> same symptoms). It did have a ServeRAID controller too but IBM suggested >> we take it out since 4500R also had problems with it on 2.4 but it didn't >> make any difference at all. Also tried to turn off highmem support but >> didn't make difference either. > >(*) redhat chose to ship an experimental compiler with this release of > the distribution that has a great many bugs. to ensure proper kernel > compillation another proven version of gcc was included, but called > kgcc instead. You should always use this to compile your kernels > under redhat 7 until the newer version of gcc is released. http://www.bero.org/gcc296.html -- Mike A. Harris - Linux advocate - Free Software advocate This message is copyright 2001, all rights reserved. Views expressed are my own, not necessarily shared by my employer. -- Red Hat Linux: http://www.redhat.com Download for free: ftp://ftp.redhat.com/pub/redhat/redhat-6.2/ - 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/
[fix]some radeon build problem
I have found some problem in building kernel with radeonfb 16bpp support at 2.4.2-ac8.
here is patch.
--- linux/drivers/video/radeonfb.c.orig Fri Mar 2 12:29:15 2001
+++ linux/drivers/video/radeonfb.c Fri Mar 2 12:29:28 2001
@@ -845,9 +845,11 @@
rinfo->depth = disp->var.bits_per_pixel;
switch (disp->var.bits_per_pixel) {
+#ifdef FBCON_HAS_CFB8
case 8:
disp->dispsw = &fbcon_cfb8;
break;
+#endif
#ifdef FBCON_HAS_CFB16
case 16:
disp->dispsw = &fbcon_cfb16;
@@ -1322,8 +1322,8 @@
i = (regno << 8) | regno;
rinfo->con_cmap.cfb32[regno] = (i << 16) | i;
break;
-#endif
}
+#endif
}
}
#endif
2.4.2-ac7 doesn't boot on K6-2
2.4.2 worked OK, but I needed loopback also, so I tried 2.4.2-ac7. I get the "uncompressing... Booting" line, and it hangs there (I let it sit for 30s to be sure). System: AMD K6-2/266, ATI Mach64, oldBusLogic SCSI card, almost evreything compiled as modules. I will try ac-8 once it shows up on the mirrors. -Eric - 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][rfc][rft] vm throughput 2.4.2-ac4
In article <[EMAIL PROTECTED]>, Rik van Riel <[EMAIL PROTECTED]> wrote: > >I haven't tested it yet for a number of reasons. The most >important one is that the FreeBSD people have been playing >with this thing for a few years now and Matt Dillon has >told me the result of their tests ;) Note that the Linux VM is certainly different enough that I doubt the comparisons are all that valid. Especially actual virtual memory mapping is basically from another planet altogether, and heuristics that are appropriate for *BSD may not really translate all that better. I'll take numbers over talk any day. At least Mike had numbers, and possible explanations for them. He also removed more code than he added, which is always a good sign. In short, please don't argue against numbers. Linus - 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.2-ac8=no ps2 mouse
My ps2 mouse isn't detected with this patch. It worked with 2.4.2-ac4. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What is 2.4 Linux networking performance like compared to BSD?
Hello Hans, Thursday, March 01, 2001, 7:26:20 AM, you wrote: HR> I have a client that wants to implement a webcache, but is very leery of HR> implementing it on Linux rather than BSD. HR> They know that iMimic's polymix performance on Linux 2.2.* is half what it is on HR> BSD. Has the Linux 2.4 networking code caught up to BSD? HR> Can I tell them not to worry about the Linux networking code strangling their HR> webcache product's performance, or not? HR> Hans HR> - HR> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in HR> the body of a message to [EMAIL PROTECTED] HR> More majordomo info at http://vger.kernel.org/majordomo-info.html HR> Please read the FAQ at http://www.tux.org/lkml/ It is not only related to TCP/IP performance. it is related to whole OS performance. especially performance of file system and stablity, network driver performance etc. FreeBSD with softupdates turned on seems horrible fast and stable. but Linux 2.4 is horrible fast in TCP/IP too. diffcult to compare between in Linux and FreeBSD. don't do such stupid thing. you'll never get a correct result. -- Best regards, David Xu - 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.x very unstable on 8-way IBM 8500R
On Thu, Mar 01, 2001 at 05:04:09PM -0800, Dr. Kelsey Hudson wrote: > On Thu, 1 Mar 2001, Matilainen Panu (NRC/Helsinki) wrote: > > > I've been playing around with 8-way IBM8500R (8x700MHz Xeon) with 4.5GB > > memory & AIC7xxx SCSI-controller. It's perfectly stable with 2.2-kernel > > (from Red Hat 7) but very erratic on all 2.4-kernels I've tried it with > > (2.4.[012], compiled both with egcs and RH7's gcc-2.96, both share the > > Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is > inherently broken(*). > For the umpteenth time, no it isn't. There are serious bugs in the shipped version of gcc in RedHat 7.0, but they are fixed by applying the update. The reason for supplying kgcc is to allow building a 2.2 kernel, because of bugs in the kernel, NOT the compiler. > > same symptoms). It did have a ServeRAID controller too but IBM suggested > > we take it out since 4500R also had problems with it on 2.4 but it didn't > > make any difference at all. Also tried to turn off highmem support but > > didn't make difference either. > > (*) redhat chose to ship an experimental compiler with this release of > the distribution that has a great many bugs. to ensure proper kernel > compillation another proven version of gcc was included, but called > kgcc instead. You should always use this to compile your kernels > under redhat 7 until the newer version of gcc is released. > No. Provided you grab the update, you can build the 2.4 kernel perfectly happily using the RedHat gcc snapshot. I'm running it successfully on a number of machines. The issue with 2.4 on certain Netfinities is a bad interaction between the NMI watchdog code and the systems management card. Changing compilers makes no difference. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/
Strange NAT messages on multicast packets
I'm seeing a lot of messages in my gateway's system log of the form: lithium kernel: NAT: 0 dropping untracket packet c233f340 1 10.38.10.67 -> 224.0.0.2 Virtually all these packets come from machines on the student LAN on the "outside" of the gateway. Whether or not iptables is configured to drop the packets (on input or forward), these messages still appear. I understand 224.0.0.2 means "multicast router", but why does my kernel have to be so verbose about it? Is there a sensible way to turn off the messages without playing havoc with my syslogd configuration? Kernel 2.4.1 on a P166/MMX, compiled with gcc 2.95.2, based on a barely-recognisable RH 6.2 installation. The NIC which these packets come in on is a 3c509, which is not in promiscuous mode. -- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) big-mail: [EMAIL PROTECTED] uni-mail: [EMAIL PROTECTED] The key to knowledge is not to rely on people to teach you it. Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/ -BEGIN GEEK CODE BLOCK- Version 3.12 GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r- y+ -END GEEK CODE BLOCK- - 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.x very unstable on 8-way IBM 8500R
Just FYI, I am chasing this problem. There appears to be an unpleasant interaction between the Advanced Systems Management card and the NMI watchdog code. Ripping the card out of the machine also eradicates the problem, but is less desirable. I'll let people know when there's a better solution. Tim On Thu, Mar 01, 2001 at 03:30:56PM +0200, Matilainen Panu (NRC/Helsinki) wrote: > On Thu, 1 Mar 2001, ext Andrew Morton wrote: > > "Matilainen Panu (NRC/Helsinki)" wrote: > > > On Thu, 1 Mar 2001, ext Andrew Morton wrote: > > > > > > > > Is it stable with `nmi_watchdog=0'? > > > > > > If the default value for nmi_watchdog is 0 then no - I added the > > > nmi_watchdog=1 just to see if that makes any difference. If it's on by > > > default then I'll need to test it that way. > > > > Default for nmi_watchdog is `enabled'. > > > > Several people have reported that turning it off with > > the `nmi_watchdog=0' LILO option makes systems stable. > > Nobody knows why. > > > > (If nmi_watchdog _does_ make the achine stable, please > > tell linux-kernel.). > > It's too early to say for sure but that seems to have fixed it. Uptime now > nearly an hour under loads of 20-30 which is way more than it has been > able to stay up before. I'll let you know whether its still up tomorrow. > > Million thanks for the tip! > > - Panu - > -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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.2ac8 lost char devices
> > > > > Well, somethig has broken in ac8, because I lost my PS/2 mouse and > > > > me too . > No luck. it seems to be the mdelay(2) added to pc_keyb.c in -ac6. - 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 IO problem on multiple PCI busses
Grant Grundler writes: > A nice side effect of this bloat is it will discourage use of I/O > Port space. That's good for everyone, AFAICT. (I know some devices > *only* support I/O port space and I personnally don't care about > them. If someone who does care about one wants to talk to me about > it...fine...I'll help) There is another case you are ignoring. Some devices support memory space as well as I/O space, but only operate reliably when their I/O space window is used to access it. It just sounds to me like the hppa pci controllers are crap, especially the GSC one. At least the rope one does something reasonable when you have a 64-bit kernel. The horrors you've told me about the IOMMUs and stream-caches on these chips further confirms my theory :-) 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: 2.4.2ac8 lost char devices
On 03.02 Mark Hahn wrote: > > > > Well, somethig has broken in ac8, because I lost my PS/2 mouse and > > > > > > me too . > > > my theory at the moment is that perhaps the new apic feature > > > killed it (I also had ioapic enabled). mine's a kt133 system... > > > > Mm, lets try noapic... > No luck. -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac7 #1 SMP Fri Mar 2 02:36:23 CET 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: APIC error on CPU0 (UP APIC kernel)
Em Thu, Mar 01, 2001 at 09:05:00PM -0500, Chaskiel M Grundman escreveu: > 2.4 SMP kernels seem to work fine, but using a 2.4.1 or 2.4.2 UP kernel can you try 2.4.2-ac8 and tell us the results? > with CONFIG_X86_UP_IOAPIC does not. At some point before the real root > filesystem is mounted, the system begins spewing - 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.2ac8 lost char devices
Hi, Well, somethig has broken in ac8, because I lost my PS/2 mouse and (less important, but perhaps it is useful) the microcode driver. So I think it something common to both. The onle diff in dmesg from ac7 to ac8 is just the errors: 1c1 < Linux version 2.4.2-ac7 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Linux-Mandrake 8.0)) #1 SMP Fri Mar 2 02:36:23 CET 2001 --- > Linux version 2.4.2-ac8 ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Linux-Mandrake 8.0)) #1 SMP Fri Mar 2 01:17:50 CET 2001 82c82 < Detected 400.917 MHz processor. --- > Detected 400.914 MHz processor. 232,237c232,237 < . CPU clock speed is 400.8934 MHz. < . host bus clock speed is 100.2232 MHz. < cpu: 0, clocks: 1002232, slice: 334077 < CPU0 < cpu: 1, clocks: 1002232, slice: 334077 < CPU1 --- > . CPU clock speed is 400.8944 MHz. > . host bus clock speed is 100.2233 MHz. > cpu: 0, clocks: 1002233, slice: 334077 > CPU0 > cpu: 1, clocks: 1002233, slice: 334077 > CPU1 245c245,246 < IA-32 Microcode Update Driver: v1.08 <[EMAIL PROTECTED]> --- > microcode: can't misc_register on minor=184 > microcode: failed to devfs_register() What is microcode doing with devfs ? I have not configured devfs... -- J.A. Magallon $> cd pub mailto:[EMAIL PROTECTED] $> more beer Linux werewolf 2.4.2-ac7 #1 SMP Fri Mar 2 02:36:23 CET 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/
APIC error on CPU0 (UP APIC kernel)
I have some single-processr Dell Poweredge 2450 servers that I'm trying to move to 2.4. They have been running 2.2 SMP kernels for a while with no problem (to take advantage of the supposed benefit of using the ioapic). 2.4 SMP kernels seem to work fine, but using a 2.4.1 or 2.4.2 UP kernel with CONFIG_X86_UP_IOAPIC does not. At some point before the real root filesystem is mounted, the system begins spewing APIC error on CPU0: 08(08) at a high rate and eventually either locks up, or is killed by the watchdog nmi (at which point control-alt-delete _works_) 2450's use a serverworks chipset. I don't know what other information might be useful... Here's an excerpt of the SMP 2.4.2 dmesg output, in case it's of any use: ENABLING IO-APIC IRQs ...changing IO-APIC physical APIC ID to 1 ... ok. ...changing IO-APIC physical APIC ID to 2 ... ok. Synchronizing Arb IDs. init IO_APIC IRQs IO-APIC (apicid-pin) 1-0, 1-2, 1-3, 1-5, 1-10, 1-11, 1-13, 2-3, 2-8, 2-9, 2-10, 2-11, 2-12, 2-13 not connected. ..TIMER: vector=49 pin1=-1 pin2=0 ...trying to set up timer (IRQ0) through the 8259. (found pin 0) ...works. activating NMI Watchdog ... done. number of MP IRQ sources: 27. number of IO-APIC #1 registers: 16. number of IO-APIC #2 registers: 16. testing the IO APIC... IO APIC #1.. register #00: 0100 ...: physical APIC id: 01 register #01: 000F0011 ... : max redirection entries: 000F ... : IO APIC version: 0011 register #02: ... : arbitration: 00 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 001 01 000 0 01131 01 001 01 000 0 01139 02 000 00 100 0 00000 03 000 00 100 0 00000 04 001 01 000 0 01141 05 000 00 100 0 00000 06 001 01 000 0 01149 07 001 01 000 0 01151 08 001 01 000 0 01159 09 001 01 000 0 01161 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 001 01 000 0 01169 0d 000 00 100 0 00000 0e 001 01 000 0 01171 0f 001 01 000 0 01179 IO APIC #2.. register #00: 0200 ...: physical APIC id: 02 register #01: 000F0011 ... : max redirection entries: 000F ... : IO APIC version: 0011 register #02: 0200 ... : arbitration: 02 IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 001 01 110 1 01181 01 001 01 110 1 01189 02 001 01 110 1 01191 03 000 00 100 0 00000 04 001 01 110 1 01199 05 001 01 110 1 011A1 06 001 01 110 1 011A9 07 001 01 110 1 011B1 08 000 00 100 0 00000 09 000 00 100 0 00000 0a 000 00 100 0 00000 0b 000 00 100 0 00000 0c 000 00 100 0 00000 0d 000 00 100 0 00000 0e 001 01 110 1 011B9 0f 001 01 110 1 011C1 IRQ to pin mappings: IRQ1 -> 1 IRQ4 -> 4 IRQ6 -> 6 IRQ7 -> 7 IRQ8 -> 8 IRQ9 -> 9 IRQ12 -> 12 IRQ14 -> 14 IRQ15 -> 15 IRQ16 -> 0 IRQ17 -> 1 IRQ18 -> 2 IRQ20 -> 4 IRQ21 -> 5 IRQ22 -> 6 IRQ23 -> 7 IRQ30 -> 14 IRQ31 -> 15 done. calibrating APIC timer ... . CPU clock speed is 731.0440 MHz. . host bus clock speed is 132.9169 MHz. cpu: 0, clocks: 1329169, slice: 664584 CPU0 Setting commenced=1, go go go PCI: PCI BIOS revision 2.10 entry at 0xfc79e, last bus=3 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: ServerWorks host bridge: last bus ff Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent PCI: Discovered primary peer bus 02 [IRQ] PCI: Using IRQ router ServerWorks [1166/0200] at 00:0f.0 PCI->APIC IRQ transform: (B0,I2,P0) -> 20 PCI->APIC IRQ transform: (B0,I8,P0) -> 22 PCI->APIC IRQ transform: (B2,I8,P0) -> 16 [...] ServerWorks OSB4: IDE controller on PCI bus 00 dev 79 ServerWorks OSB4: chipset revision 0 ServerWorks OSB4: not 100% native mode: will probe irqs later ide0: BM-DMA at 0x08b0-0x08b7, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0x08b8-0x08bf, BIOS settings: hdc:pio, hdd:pio hda: TOSHIBA CD-ROM XM-7002B, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 [...]
Re: 2.4.x very unstable on 8-way IBM 8500R
"Dr. Kelsey Hudson" wrote: > Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is > inherently broken(*). Or upgrade to the current Red Hat 7 gcc, which works quite well. 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/
[Newbie] Re: Problem creating filesystem
On Feb 26 2001, Jeremy Jackson wrote: > Carlos Fernandez Sanz wrote: > > The IDE controller is > > Bus 0, device 17, function 0: > > Unknown mass storage controller: Promise Technology Unknown device (rev > > 2). > > Vendor id=105a. Device id=d30. > > Medium devsel. IRQ 10. Master Capable. Latency=32. > > Unrelated to disk "problem", you might want to set your PCI latency timer in > BIOS to 64 or more. Ok, I understand that this is probably off-topic and way too basic, but what exactly would this do, in layman terms? Would the latency being set to 32 result in any potential data corruption? BTW, to set this quantity, one should use setpci, right? Thanks for any help, Roger... -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rogerio Brito - [EMAIL PROTECTED] - http://www.ime.usp.br/~rbrito/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - 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.2-ac6 hangs on boot w/AMD Elan SC520 dev board
I spent some time testing the previous patch today. I found a couple of corner cases
that weren't handled correctly in the first version.
I've attached a new version (against 2.4.2-ac7) that should fix those problems.
Brian
[EMAIL PROTECTED]
--- linux-2.4.2-ac7/arch/i386/kernel/setup.cThu Mar 1 15:39:08 2001
+++ linux/arch/i386/kernel/setup.c Thu Mar 1 15:59:06 2001
@@ -58,6 +58,9 @@
* Massive cleanup of CPU detection and bug handling;
* Transmeta CPU detection,
* H. Peter Anvin <[EMAIL PROTECTED]>, November 2000
+ *
+ * Added E820 sanitization routine (removes overlapping memory regions);
+ * Brian Moyle <[EMAIL PROTECTED]>, February 2001
*/
/*
@@ -438,6 +441,170 @@
}
/*
+ * Sanitize the BIOS e820 map.
+ *
+ * Some e820 responses include overlapping entries. The following
+ * replaces the original e820 map with a new one, removing overlaps.
+ *
+ */
+static int __init sanitize_e820_map(struct e820entry * biosmap, char * pnr_map)
+{
+ struct change_member {
+ struct e820entry *pbios; /* pointer to original bios entry */
+ unsigned long long addr; /* address for this change point */
+ };
+ struct change_member change_point_list[2*E820MAX];
+ struct change_member *change_point[2*E820MAX];
+ struct e820entry *overlap_list[E820MAX];
+ struct e820entry new_bios[E820MAX];
+ struct change_member *change_tmp;
+ unsigned long current_type, last_type;
+ unsigned long long last_addr;
+ int chgidx, still_changing;
+ int overlap_entries;
+ int new_bios_entry;
+ int old_nr, new_nr;
+ int i;
+
+ /*
+ Visually we're performing the following (1,2,3,4 = memory types)...
+
+ Sample memory map (w/overlaps):
+ 22__
+ __4_
+
+ _44_
+
+ 33__
+ ___44___
+ __3_
+ __22
+ ____
+ _1__
+ _11_
+ _4__
+
+ Sanitized equivalent (no overlap):
+ 1___
+ _44_
+ ___1
+ 22__
+ __11
+ _1__
+ __3_
+ ___44___
+ _33_
+ ___2
+ 1___
+ _4__
+ ___2
+ 33__
+ __4_
+ */
+
+ /* if there's only one memory region, don't bother */
+ if (*pnr_map < 2)
+ return -1;
+
+ old_nr = *pnr_map;
+
+ /* bail out if we find any unreasonable addresses in bios map */
+ for (i=0; iaddr = biosmap[i].addr;
+ change_point[chgidx++]->pbios = &biosmap[i];
+ change_point[chgidx]->addr = biosmap[i].addr + biosmap[i].size;
+ change_point[chgidx++]->pbios = &biosmap[i];
+ }
+
+ /* sort change-point list by memory addresses (low -> high) */
+ still_changing = 1;
+ while (still_changing) {
+ still_changing = 0;
+ for (i=1; i < 2*old_nr; i++) {
+ /* if > , swap */
+ /* or, if current= & last=, swap */
+ if ((change_point[i]->addr < change_point[i-1]->addr) ||
+ ((change_point[i]->addr == change_point[i-1]->addr) &&
+(change_point[i]->addr ==
+change_point[i]->pbios->addr) &&
+(change_point[i-1]->addr !=
+change_point[i-1]->pbios->addr))
+ )
+ {
+ change_tmp = change_point[i];
+ change_point[i] = change_point[i-1];
+ change_point[i-1] = change_tmp;
+ still_changing=1;
+ }
+ }
+ }
+
+ /* create a new bios memory map, removing overlaps */
+ overlap_entries=0; /* number of entries in the overlap table */
+ new_bios_entry=0;/* index for creating new bios map entries */
+ last_type = 0; /* start with undefined memory type */
+ last_addr = 0; /* start with 0 as last starting address */
+ /* loop through
Re: 2.4.x very unstable on 8-way IBM 8500R
> > (from Red Hat 7) but very erratic on all 2.4-kernels I've tried it with > > (2.4.[012], compiled both with egcs and RH7's gcc-2.96, both share the > Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is So he was using egcs, and whether he had the pre-errata gcc 2.96 wouldnt matter - 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 IO problem on multiple PCI busses
Benjamin Herrenschmidt wrote:
> Hi Grant !
>
> Alan Cox suggested I contact you about this. I'm trying to figure out a
> way to cleanly resolve the problem of doing IO accesses on machines with
> multiple PCI host bridges (and multiple IO bases when IO cycles are not
> generated by the CPU). I'd be glad if you could catch on the
> "The IO problem on multiple PCI busses" thread on linux-kernel list
> and let us share your point of viw.
To l-k, Benjamin wrote:
| I've looked at the parisc code (thanks Alan for pointing that out), and
| it seem they implement all inb/outb as quite big functions that decypher
| the address, retreive the bus, and do the proper IO call. Unfortunately,
| that's a bit bloated, and I don't think I'll ever get other PPC
| maintainers to agree with such a mecanism (everybody seem to be quite
| concerned with IO speed, I admit including me).
Benjamin,
As the main author/maintainer of that code, let me explain why
it's so ugly. Hopefully this will give you insight into a "better"
(arch independent) solution. Apologies for the length.
For IO Port space, I didn't worry about the bloat. A nice side effect of
this bloat is it will discourage use of I/O Port space. That's good for
everyone, AFAICT. (I know some devices *only* support I/O port space and
I personnally don't care about them. If someone who does care about one
wants to talk to me about it...fine...I'll help)
[ Caveat: I've simplified the following *alot* to keep it short. ]
parisc supports two different PCI host bus adapters with each having
variants that behave differently. All work under the model we are using
with one binary. One kernel binary is important since we want to make
install's easy for users.
Under Dino (GSCtoPCI), each PCI HBA has it's own 64K I/O port space.
I/O port space transactions are generated by poking registers on Dino.
Yes - performance sucks - that's why HPUX (almost) exclusively
uses devices which support MMIO.
Under Elroy (aka LBA or RopesToPCI), we have two methods of accessing
I/O port space. One view of I/O space can be shared across all Elroy's
which share the same IOMMU (aka SBA). This method distributes the 64K
I/O space over the 8 (or 16) "ropes" with rope 0 getting the first
8k (or 4k) and so on. The other view is each LBA has it's own 64K
of I/O port space. The second view is mapped above 4GB and requires
64-bit kernel to access. In both cases, processor loads/stores from/to
the region will generate an I/O cycle on the respective PCI bus.
Generally speaking, parisc doesn't support VGA or ISA legacy crud on
it's PCI busses. But I think those are orthogonal issues.
The inb/outb support hings on this definition in include/asm-parisc/pci.h:
struct pci_port_ops {
u8 (*inb) (struct pci_hba_data *hba, u16 port);
u16 (*inw) (struct pci_hba_data *hba, u16 port);
u32 (*inl) (struct pci_hba_data *hba, u16 port);
void (*outb) (struct pci_hba_data *hba, u16 port, u8 data);
void (*outw) (struct pci_hba_data *hba, u16 port, u16 data);
void (*outl) (struct pci_hba_data *hba, u16 port, u32 data);
};
Code which uses this is in arch/parisc/kernel/pci.c at:
http://puffin.external.hp.com/cvs/linux/arch/parisc/kernel/pci.c
(look for PCI_PORT_HBA usage)
In a nut shell, the HBA number is encoded in the upper 16-bits
of the 32-bit I/O port space address. The inb() *function* uses the
decoded HBA number to lookup the matching pci_port_ops function table
and pci_hba_data * to pass in. PCI fixup_bus() code virtualizes the
I/O port addresses found by the generic PCI bus walk. inb() is
function so drivers work under *all* parisc PCI HBAs with one binary.
This scheme allows us to support "PCI-like" busses as well.
Some parisc machines have both PCI and EISA slots which are completely
independent of each other. We'd like to keep the semantics of inb/outb
the same and support both at the same time. It might be possible
to do this by feeding the drivers different versions of inb/outb
definitions at compile time. But initial attempts to do this ran
into problems (which I don't remember the details of).
Last comment is regarding who *configures* the PCI devices. On legacy PDC
(parisc's "BIOS on steriods"), the PDC sets everything up but does
not enable everything (ie pci_enable_device will set bits in PCI_COMMAND
cfg register). On card-mode Dino, (GSC cards plugged in proprietary bus),
the firmware doesn't know *anything* about the PCI devices and the arch
support has to set everything up - PCI MMIO space is not currently
supported there. And new servers (like L2000 or A500) with "PAT PDC" only
initialize PCI devices for boot. OS has to initialize the rest.
grant
Grant Grundler
parisc-linux {PCI|IOMMU|SMP} hacker
+1.408.447.7253
-
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 a
[BUG] 2.4.x system Freezes
Hi, A couple of weeks age I reported a couple of problems. The first two turned out not to be serious but the third, where the system freezes, has not stopped happening. Several other people have reported similar problems... Typically my system will die while kde2.1 is starting (about 1 time in 4) or shortly after I start a caching news server (newsplex), another common trigger is dpkg, when reading its database just before it starts up unpack packages. If it gets thru these hurdles it may last up to three days - most of the time I am luckly to get one... Once it hangs its really hung. A ups cannot trigger a shutdown, sysrq is dead, the num lock indicator will not toggle. Trying to use shift, alt or control + shiftlock does not result in any data on a serial console, nor are there any unexpected messages there. Also pinging from the box running the serial console gets no answers during a stall. The software watchdog does not get triggered either. I would love NOT to have to be such close friends with the reset button. (reiserfs has been very usefully with all the crashes...) I have install kdb on the off chance that I can hit PAUSE fast enought to it to do a bt command one time it freezes. What else can be done to debug this? Could this be related to the memory problems reported reciently? TIA Ed Tomlinson <[EMAIL PROTECTED]> Current kernel is 2.4.2-ac7 + kdb 1.8 K6-III 400 via mp3 128M mga400max AGP (x1) with xfree 4.02 driver SB16 ISA, nonpnp using alsa 5.10b drivers USR ISA modem, nonpnp Tuplip based card connected to an small internal 100BaseT network VIA Rhine based cards connected to a 10BaseT xDSL modem no scsi hda=13G hdb=4.3G (both quantum, UDMA2) hdc=CDROM hdd=tape (both ATAPI PIO) usb optical MS mouse My root filesystem is on reiserfs and reiserfsck tells me its fine when booted from a recovery partition. On Feb 6 Ed Tomlinson wrote: >System hangs. This box has been quite stable. The hangs started >appearing around 2.4.1 or so. I very much doubt they are heat releated. I >have had heat problems in the past an have moved the kit into a much better >case. The old symptoms (ide tape problems) have gone and not returned even >on the hotest summer day... Next time this happens I will try to telnet or >ssh into box to see if anything is active, I will also setup a UPS on the >box and see it that can shut it down. Its interesting that the software >watchdog does not get triggered. - 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.x very unstable on 8-way IBM 8500R
On Thu, 1 Mar 2001, Matilainen Panu (NRC/Helsinki) wrote: > I've been playing around with 8-way IBM8500R (8x700MHz Xeon) with 4.5GB > memory & AIC7xxx SCSI-controller. It's perfectly stable with 2.2-kernel > (from Red Hat 7) but very erratic on all 2.4-kernels I've tried it with > (2.4.[012], compiled both with egcs and RH7's gcc-2.96, both share the Under redhat 7 you should use kgcc to compile the kernel, since gcc2.96 is inherently broken(*). > same symptoms). It did have a ServeRAID controller too but IBM suggested > we take it out since 4500R also had problems with it on 2.4 but it didn't > make any difference at all. Also tried to turn off highmem support but > didn't make difference either. (*) redhat chose to ship an experimental compiler with this release of the distribution that has a great many bugs. to ensure proper kernel compillation another proven version of gcc was included, but called kgcc instead. You should always use this to compile your kernels under redhat 7 until the newer version of gcc is released. talk to you later, Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: negative mod use count
On Wed, 28 Feb 2001, Boris Dragovic wrote: > what does negative module use count mean? That means that there's a bug in someone's driver. For some reason, the function to decrement the module use is called more than once when a controlling process releases use of a module. This will prevent you from being able to 'rmmod' or 'modprobe -r' it; a "Device or resource busy" error or similar will result IIRC. Submit a bug to the driver maintainer. Kelsey Hudson [EMAIL PROTECTED] Software Engineer Compendium Technologies, Inc (619) 725-0771 --- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Another rsync over ssh hang (repeatable, with 2.4.1 on both ends)
I have a fairly repeatable rsync over ssh stall that I'm seeing between two Linux boxes, both running identical 2.4.1 kernels. The stall is fairly easy to repeat in our environment -- it can happen up to several times per minute, and usually happens at least once per minute. It doesn't really seem to be data-sensitive. The stall will last until the session times out *unless* I take one of two steps to "unstall" it. The easiest way to do this is to run 'strace -p $PID' against the sending ssh process. As soon as the strace is started, rsync starts working again, but will stall again (even with strace still running) after a short period of time. We've seen this bug (or a *very* similar one) with 2.2.16 and 2.4.[01]. I haven't tried a newer 2.2.x or 2.4.2 or -acX. One system is a P2/400, the other is a P3/800. The two boxes are communicating over a mostly idle Ethernet, through 3 switches. One end is a EEPro 100, the other end is an Acenic, although that shouldn't matter. During a stall, the sending end shows a lot of data stuck in the Recv-Q: Proto Recv-Q Send-Q Local Address Foreign Address State tcp72848 0 ref.lab.ocp.interna:840 ref-0.sys.pnap.net:ssh ESTABLISHED The receiving end shows a similar problem, but on the sending queue: Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 28960 ref-0.sys.pnap.net:ssh ref.lab.ocp.interna:840 ESTABLISHED Like I said, I don't believe that this is a network issue, because I can un-stall the rsync by either stracing the *sending* ssh process, or by putting the sending rsync into the background with ^Z and then popping it back into the foreground. I have tcpdumps that I can send, but they look pretty straightforward to me -- the window fills, so data stops flowing. Strace doesn't seem to be particularly informative: select(4, [0], [1], NULL, NULL) = 1 (out [1]) write(1, "x"..., 66156) = 66156 ... select(4, [0], [1 3], NULL, NULL) = 2 (out [1 3]) write(1, "\0\0\0\0\274\2\0\0\0\0\0\0\271\30\0\0\0\0\0\0\274\2\0\0"..., 69526 Strace on the receiving end shows the obvious -- it's sitting in select waiting for data to arrive. According to 'ps l', the ssh process is waiting in 'sock_wait_for_wmem'. We've tried changing versions of rsync and ssh without any success. FWIW, this kernel was compiled with GCC 2.95.2, from Debian potato. Scott - 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] reiserfs patch for linux-2.4.2
Christoph Hellwig writes: > On Wed, Feb 28, 2001 at 10:16:02PM -0500, Albert D. Cahalan wrote: >> Christoph Hellwig writes: >> >>> Urgg. limits.h is a userlevel header... >>> >>> The attached patch will make similar atempts fail (but not this one as >>> there is also a limits.h in gcc's include dir). >> >> There are very few files needed from gcc's include dir. Linux ought to >> be able to survive without them. Linux is already gcc-specific anyway. > > I think we want stdarg.h from gcc... Yes, just as apps want files. The kernel can have a copy. If the stack frame layout changes enough to cause trouble with stdarg.h, then most likely there will be huge trouble in 42 other places. If you insist on using whatever random stdarg.h might be on the system, then just copy it into the build area. The compile might even run a bit faster without the extra directory to search. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] pci_set_dma_mask() + doc :)
please feel free to flame or apply, I'm not sure I'm really fond of the
code example..
- z
--- linux-2.4.2/include/linux/pci.h.dmasup Wed Feb 28 10:26:14 2001
+++ linux-2.4.2/include/linux/pci.h Wed Feb 28 10:30:12 2001
@@ -527,6 +527,7 @@
int pci_enable_device(struct pci_dev *dev);
void pci_set_master(struct pci_dev *dev);
+int pci_set_dma_mask(struct pci_dev *dev, dma_addr_t mask);
int pci_set_power_state(struct pci_dev *dev, int state);
int pci_assign_resource(struct pci_dev *dev, int i);
--- linux-2.4.2/include/asm-i386/pci.h.dmasup Wed Feb 28 10:19:01 2001
+++ linux-2.4.2/include/asm-i386/pci.h Wed Feb 28 10:25:40 2001
@@ -152,6 +152,14 @@
*/
extern inline int pci_dma_supported(struct pci_dev *hwdev, dma_addr_t mask)
{
+/*
+ * we fall back to GFP_DMA when the mask isn't all 1s,
+ * so we can't guarantee allocations that must be
+ * within a tighter range than GFP_DMA..
+ */
+if(mask < 0x00ff)
+return 0;
+
return 1;
}
--- linux-2.4.2/drivers/pci/pci.c.dmasupWed Feb 28 10:26:34 2001
+++ linux-2.4.2/drivers/pci/pci.c Thu Mar 1 19:04:35 2001
@@ -518,6 +518,18 @@
pcibios_set_master(dev);
}
+int
+pci_set_dma_mask(struct pci_dev *dev, dma_addr_t mask)
+{
+if(! pci_dma_supported(dev, mask))
+return -EIO;
+
+dev->dma_mask = mask;
+
+return 0;
+}
+
+
/*
* Translate the low bits of the PCI base
* to the resource type
@@ -1206,6 +1218,7 @@
EXPORT_SYMBOL(pci_find_slot);
EXPORT_SYMBOL(pci_find_subsys);
EXPORT_SYMBOL(pci_set_master);
+EXPORT_SYMBOL(pci_set_dma_mask);
EXPORT_SYMBOL(pci_set_power_state);
EXPORT_SYMBOL(pci_assign_resource);
EXPORT_SYMBOL(pci_register_driver);
--- linux-2.4.2/Documentation/DMA-mapping.txt.dmasupWed Feb 28 23:03:04 2001
+++ linux-2.4.2/Documentation/DMA-mapping.txt Thu Mar 1 19:29:38 2001
@@ -71,12 +71,35 @@
if (! pci_dma_supported(pdev, 0x00ff))
goto ignore_this_device;
+When DMA is possible for a given mask, the PCI layer must be informed of the
+mask for later allocation operations on the device. This is achieved by
+setting the dma_mask member of the pci_dev structure, like so:
+
+#define MY_HW_DMA_MASK 0x00ff
+
+ if (! pci_dma_supported(pdev, MY_HW_DMA_MASK))
+ goto ignore_this_device;
+
+ pdev->dma_mask = MY_HW_DMA_MASK;
+
+A helper function is provided which performs this common code sequence:
+
+ int pci_set_dma_mask(struct pci_dev *pdev, dma_addr_t device_mask)
+
+Unlike pci_dma_supported(), this returns -EIO when the PCI layer will not be
+able to DMA with addresses restricted by that mask, and returns 0 when DMA
+transfers are possible. If the call succeeds, the dma_mask will have been
+updated so that your driver need not worry about it.
+
There is a case which we are aware of at this time, which is worth
mentioning in this documentation. If your device supports multiple
functions (for example a sound card provides playback and record
functions) and the various different functions have _different_
DMA addressing limitations, you may wish to probe each mask and
-only provide the functionality which the machine can handle.
+only provide the functionality which the machine can handle. It
+is important that the last call to pci_set_dma_mask() be for the
+most specific mask.
+
Here is pseudo-code showing how this might be done:
#define PLAYBACK_ADDRESS_BITS 0x
@@ -86,14 +109,14 @@
struct pci_dev *pdev;
...
- if (pci_dma_supported(pdev, PLAYBACK_ADDRESS_BITS)) {
+ if (pci_set_dma_mask(pdev, PLAYBACK_ADDRESS_BITS)) {
card->playback_enabled = 1;
} else {
card->playback_enabled = 0;
printk(KERN_WARN "%s: Playback disabled due to DMA limitations.\n",
card->name);
}
- if (pci_dma_supported(pdev, RECORD_ADDRESS_BITS)) {
+ if (pci_set_dma_mask(pdev, RECORD_ADDRESS_BITS)) {
card->record_enabled = 1;
} else {
card->record_enabled = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: fat problem in 2.4.2
Alexander Viro writes: [about file expansion by truncate] > Basically, the program depends on behaviour that was never guaranteed > to be there. 1. it is useful 2. it is documented in a few places AFAIK 3. it is portable enough for Star Office (Solaris I guess) > BTW, _some_ subset is doable on FAT. You can't always do it (bloody > thing doesn't support holes), but you can try the following (warning - > untested patch): Holes are nothing special. They are just a simple type of compression. We are doing overcommit on filesystems, and need an OOD killer to wipe out big files like the Star Office executable. - 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/
IO Clustering & Delayed allocation
Below is a partial patch to provide hooks so
that IO clustering can be performed by the file-system.
As presented, the same code is used to perform delayed allocation.
There has also been a lot of talk about implementing delayed
allocation. To be clear, delayed allocation means not
immediately allocating disk space on writing the data,
say during a sys_write. Instead, allocation of disk blocks
to logical blocks is done at the time the logical block
needs to be written out.
In the end, it looks like taking care of delayed-allocation
at writepage() is the best way to go. Following is a patch
where buffer-based routines will employ writepage() to do
such conversions. In addition to allocating blocks for a single
buffer or page, extent based filesystems would allocate blocks
for all delayed allocate blocks for the entire extent. These
same hooks can be used for clustering (i.e. pushing out
contiguous on-disk) as well.
Comments, suggestions welcome.
ananth.
--
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
--- ../../linux-2.4.2/linux/fs/buffer.c Fri Feb 9 11:29:44 2001
+++ fs/buffer.c Thu Mar 1 11:02:01 2001
@@ -161,6 +161,40 @@
atomic_dec(&bh->b_count);
}
+
+#define buffer_delay_busy(bh) \
+ (test_bit(BH_Delay, &bh->b_state) && bh->b_page && PageLocked(bh->b_page))
+
+static void
+_write_buffer(struct buffer_head *bh)
+{
+ struct page *page = bh->b_page;
+
+ if (!page || TryLockPage(page)) {
+ if (current->need_resched)
+ schedule();
+ return;
+ }
+ /*
+* Raced with someone?
+*/
+ if (page->buffers != bh || !buffer_delay(bh) || !buffer_dirty(bh)) {
+ UnlockPage(page);
+ return;
+ }
+ page->mapping->a_ops->writepage(page);
+}
+
+static inline void
+write_buffer(struct buffer_head *bh)
+{
+ if (!buffer_delay(bh))
+ ll_rw_block(WRITE, 1, &bh);
+ else
+ _write_buffer(bh);
+}
+
+
/* Call sync_buffers with wait!=0 to ensure that the call does not
* return until all buffer writes have completed. Sync() may return
* before the writes have finished; fsync() may not.
@@ -232,7 +266,7 @@
atomic_inc(&bh->b_count);
spin_unlock(&lru_list_lock);
- ll_rw_block(WRITE, 1, &bh);
+ write_buffer(bh);
atomic_dec(&bh->b_count);
retry = 1;
goto repeat;
@@ -507,6 +541,8 @@
struct bh_free_head *head = &free_list[BUFSIZE_INDEX(bh->b_size)];
struct buffer_head **bhp = &head->list;
+ if (test_bit(BH_Delay, &bh->b_state))
+ BUG();
bh->b_state = 0;
spin_lock(&head->lock);
@@ -879,7 +915,7 @@
if (buffer_dirty(bh)) {
atomic_inc(&bh->b_count);
spin_unlock(&lru_list_lock);
- ll_rw_block(WRITE, 1, &bh);
+ write_buffer(bh);
brelse(bh);
spin_lock(&lru_list_lock);
}
@@ -1394,6 +1430,11 @@
head = page->buffers;
bh = head;
+
+ if (buffer_delay(bh)) {
+ page->mapping->a_ops->writepage_nounlock(page);
+ return 0; /* just started I/O ... likely didn't complete */
+ }
do {
unsigned int next_off = curr_off + bh->b_size;
next = bh->b_this_page;
@@ -2334,7 +2375,7 @@
if (wait > 1)
__wait_on_buffer(p);
} else if (buffer_dirty(p))
- ll_rw_block(WRITE, 1, &p);
+ write_buffer(p);
} while (tmp != bh);
}
@@ -2361,6 +2402,11 @@
int index = BUFSIZE_INDEX(bh->b_size);
int loop = 0;
+ if (buffer_delay(bh)) {
+ if (wait)
+ page->mapping->a_ops->writepage_nounlock(page);
+ return 0; /* just started I/O ... likely didn't complete */
+ }
cleaned_buffers_try_again:
spin_lock(&lru_list_lock);
write_lock(&hash_table_lock);
@@ -2562,7 +2608,7 @@
__refile_buffer(bh);
continue;
}
- if (buffer_locked(bh))
+ if (buffer_locked(bh) || buffer_delay_busy(bh))
continue;
if (check_flushtime) {
@@ -2580,7 +2626,7 @@
/* OK, now we are committed to write it out. */
atomic_inc(&bh->b_count);
spin_unlock(&lru_list_lock);
- ll_rw_block(WRITE, 1, &bh);
+
Re: smartmedia adapter support??
I will not agree to the terms of usage to obtain the file, if you wish to send it to me to disect, please do. On Thu, 1 Mar 2001, Steffen Grunewald wrote: > On Thu 2001-03-01 (10:00), Tim Walberg wrote: > > Just wondering whether anyone has successfully gotten > > either a PCMCIA SmartMedia Adapter (specifically the > > Viking Components one) or a FlashPath floppy SmartMedia > > adapter working under 2.4.x. I've got both, and haven't > > gotten either working under either 2.2.x or 2.4.x, but > > I haven't had the time to work real hard at it either, > > so I'm hoping someone can give me some pointers... > > http://www.smartdisk.com has a driver (which includes a binary- > only library) for FlashPath that you can compile for your kernel > > Works fine here (2.2.16) > > Don't know about PCMCIA though > > Steffen > -- > Steffen Grunewald | GFZ | PB 2.2 | Telegrafenberg E3 | D-14473 Potsdam > » email: steffen(at)gfz-potsdam.de | fax/fon: +49-331-288-1266/-1245 « > Software is like sex - it's better when it's free. --- Linus Torvalds > - > 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/ > 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: smartmedia adapter support??
On Thu, 1 Mar 2001, Tim Walberg wrote:
> Just wondering whether anyone has successfully gotten
> either a PCMCIA SmartMedia Adapter (specifically the
> Viking Components one) or a FlashPath floppy SmartMedia
> adapter working under 2.4.x. I've got both, and haven't
> gotten either working under either 2.2.x or 2.4.x, but
> I haven't had the time to work real hard at it either,
> so I'm hoping someone can give me some pointers...
That is going to be a SDA device and will have another form of content
protection like CPRM and Linux will not support that superset of features
at this time or in the future. SMA's are on the hit list for music by the
SDMI. If you want to use it as as standard ATA device cool, but the
0xD{0123} opt-codes are not public yet and fall under CFA.
Because it does not use a public spec and I can not release the private
one.well you get the point.
Regards,
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: What is 2.4 Linux networking performance like compared to BSD?
Tigran Aivazian wrote: > > On Thu, 1 Mar 2001, Hans Reiser wrote: > > > > This is indeed what we should do if we get no answer from the list by someone > > who has already done such work. > > > > Hans, > > exactly what you want to measure? I have UP, 2way-SMP and 4way-SMP > machines all of which have at least Linux+FreeBSD installed. All my tests > so far (e.g. comparing NFS servers or filesystems etc) showed Linux (2.4) > to be a lot faster than FreeBSD in all areas. However, to get specific > answers you need to ask specific questions. Ask and you shall receive. > > (things like SPEC SFS results I can't tell because it is illegal (without > going through proper steps of publishing them), I shouldn't even be saying > that they show Linux to be much faster :) > > Regards, > Tigran Thanks Tigan, you helped me move the client past the Linux vs. BSD issue. Hans - 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 on a AMD7409 controller with kernel 2.4.2
On Thu, 1 Mar 2001, Hylke van der Schaaf wrote: > With kernet 2.2.18 DMA mode for my harddisks worked just fine, > getting IDE DMA working on an AMD7409 controller with kernel 2.4.2 is a problem. > > questions: > Why is DMA disabled on revision < C4? > How can I gat DMA working again? AMD7409: disabling single-word DMA support (revision < C4) This is not Ultra DMA it is the class of orignal from ATA-1/2 > > The Information: > > in 2.2.18 I get: > - dmesg: -- > PCI_IDE: unknown IDE controller on PCI bus 00 device 39, VID=1022, DID=7409 > PCI_IDE: not 100% native mode: will probe irqs later > ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:pio > PCI_IDE: simplex device: DMA disabled > ide1: PCI_IDE Bus-Master DMA disabled (BIOS) > hda: IBM-DPTA-372050, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hda: IBM-DPTA-372050, 19574MB w/1961kB Cache, CHS=2495/255/63 > --- > > hylke:/home/hylke# hdparm -v /dev/hda > > /dev/hda: > multcount= 16 (on) > I/O support = 1 (32-bit) > unmaskirq= 1 (on) > using_dma= 1 (on) > keepsettings = 0 (off) > nowerr = 0 (off) > readonly = 0 (off) > readahead= 8 (on) > geometry = 2495/255/63, sectors = 40088160, start = 0 > hylke:/home/hylke# hdparm -tT /dev/hda > > /dev/hda: > Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec > Timing buffered disk reads: 64 MB in 2.85 seconds = 22.46 MB/sec > > > All was fine. > I compiled 2.4.2, with: > > CONFIG_BLK_DEV_IDEPCI=y > CONFIG_IDEPCI_SHARE_IRQ=y > CONFIG_BLK_DEV_IDEDMA_PCI=y > CONFIG_IDEDMA_PCI_AUTO=y > CONFIG_BLK_DEV_IDEDMA=y > CONFIG_IDEDMA_PCI_WIP=y > CONFIG_AMD7409_OVERRIDE=y > CONFIG_IDEDMA_AUTO=y > CONFIG_IDEDMA_IVB=y > > and I get: > > - dmesg: -- > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx > AMD7409: IDE controller on PCI bus 00 dev 39 > AMD7409: chipset revision 3 > AMD7409: not 100% native mode: will probe irqs later > AMD7409: disabling single-word DMA support (revision < C4) > AMD7409: simplex device: DMA forced > ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA > hda: IBM-DPTA-372050, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > hda: 40088160 sectors (20525 MB) w/1961KiB Cache, CHS=2495/255/63 > -- > hylke:/home/hylke# hdparm -v /dev/hda > > /dev/hda: > multcount= 16 (on) > I/O support = 1 (32-bit) > unmaskirq= 1 (on) > using_dma= 0 (off) > keepsettings = 0 (off) > nowerr = 0 (off) > readonly = 0 (off) > readahead= 8 (on) > geometry = 2495/255/63, sectors = 40088160, start = 0 > hylke:/home/hylke# hdparm -d1 /dev/hda > > /dev/hda: > setting using_dma to 1 (on) > HDIO_SET_DMA failed: Operation not permitted > using_dma= 0 (off) > hylke:/home/hylke# hdparm -tT /dev/hda > > /dev/hda: > Timing buffer-cache reads: 128 MB in 0.90 seconds =142.22 MB/sec > Timing buffered disk reads: 64 MB in 12.59 seconds = 5.08 MB/sec > - > > My harddisk speed is down to 25%... > > Greets, > Hylke van der Schaaf > > > -- > Hi, I'm a signature virus. plz set me as your signature and help me > spread :) > - > 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/ > Andre Hedrick Linux ATA Development ASL Kernel Development - ASL, Inc. Toll free: 1-877-ASL-3535 1757 Houret Court Fax: 1-408-941-2071 Milpitas, CA 95035Web: www.aslab.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/
Linux 2.4.2ac8
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ 2.4.2-ac8 o Fix loop over loop crash(Jens Axboe) o Fix radeon build problems (ISHIKAWA Mutsumi) o Stop two people claiming the same misc dev id (Philipp Rumpf) o capable not suser on sx.c (Rob Radez) o Fix an ixj build combination bug(Andrzej Krzysztofowicz) o Add integrator to ARM machines (Russell King) o ARM include/constant cleanups (Russell King) o Update ARM vmlinuz.in (Russell King) o ARM i2c fixes (Russell King) o ARM scsi updates(Russell King) o ARM header updates (Russell King) o Handle E820 bios returns with overlaps (Brian Moyle) o Fix a sparc64 include build bug (Andrzej Krzysztofowicz) o Loop race fix (Jens Axboe) o s_maxbytes wasnt set for old style compat (Chris Dukes) mounts in reiserfs o Fix the fact we dont see all busses on some (Don Dupuis) Compaq machines o Fix missing watchdog configure.help (Fernando Fuganti) o Fix oom deadlock (hopefully)(Rik van Riel) o Fix binfmt_aout sign handling bug (Andrew Morton) 2.4.2-ac7 o Fusion driver updates (Steve Ralston) o Olympic fix (Andrew Morton) o Work around hardware bug in older Rage128 (Gareth Hughes) o Handle broken PIV MP tables with a NULL ioapic o Use capable in esp serial driver(Rob Radez) o Use capable not suser in console(Rob Radez) o Small networking fixups (Dave Miller) o Fix make menuconfig breakage(Keith Owens) o Enable cmpxchg8 on Rise P6 (Dave Jones) o Fix wakeup losses on cpu_allowed using tasks(Manfred Spraul) o Maestro3 now works with > 256Mb of ram (Zach Brown) o Opl3sa2 isapnp=0 handling was wrong (Jérôme Augé) | I've fixed it a little differently however o Turn off slow kmem chain check if not doing (Ingo Molnar, me) slab debugging o Fix cpu speed checking code (Mikael Pettersson) o Make bus computation more accurate (me) o Advantech watchdog driver (Marek Michalkiewicz) o dz.c serial clean up(Rob Radez) o Fix MSG_TRUNC for OOB TCP (Ingo Molnar) o Fix oops on unconfigured loop (Arjan van de Ven) o Drop nbd ll_rw_blk change (Linus has spoken ;)) o pci resource api(Jeff Garzik) o Further Natsemi updates (Don Becker, Jeff Garzik) o Switch aurora serial to capable() (Rob Radez) o Radeon frame buffer (Ani Joshi) 2.4.2-ac6 o Remove incorrect modules doc changes(Keith Owens) o Fix elf.h defines (Keith Owens) o Add 0x2B mtrr decode for intel/cyrix III(me) o Make bigmem balancing somewhat saner(Mark Hemment) o Update irda (Dag Brattli) o New FIR dongle support (Dag Brattli) o 3ware driver updates(Adam Radford) o Further reiserfs tail conversion fixes (Chris Mason) o Fix tpqic02 to use capable (Rob Radez) o Set last_rx on comtrol hostess driver (Arnaldo Carvalho de Melo) o Raid Oops fix (Neil Brown) o Fix last_rx/skb refs on cyc_x25 (Arnaldo Carvalho de Melo) o Fix last_rx/skb refs on 3c589 (Arnaldo Carvalho de Melo) o Highmem fixes for deadlock (Andrea Arcangeli, Ingo Molnar) o Another minor tulip fix (Jeff Garzik) o Fix hinote and maybe other ps/aux hangs (me, Mark Clegg) o Fix resource handling on 53c7xxx(Rasmus Andersen) o Fix scsi_register failure handling on AMD scsi (Rasmus Andersen) o Fix resource handling on aha1740(Rasmus Andersen) o Fix resource handling on blz1230
[PATCH] ac7: page_launder() & refill_inactive() changes
Hi,
The following patch changes two things:
- Counts asynchronous ll_rw_block() IO in the flushed pages counter (page_launder)
- Limits the amount of scanned pte's _by user tasks_ inside swap_out()
diff --exclude-from=/home/marcelo/exclude -Nur linux.orig/fs/buffer.c linux/fs/buffer.c
--- linux.orig/fs/buffer.c Thu Mar 1 19:21:02 2001
+++ linux/fs/buffer.c Thu Mar 1 19:33:38 2001
@@ -1399,7 +1399,8 @@
* instead.
*/
if (!offset) {
- if (!try_to_free_buffers(page, 0)) {
+ try_to_free_buffers(page, 0);
+ if (page->buffers) {
atomic_inc(&buffermem_pages);
return 0;
}
@@ -2413,7 +2414,7 @@
spin_unlock(&free_list[index].lock);
write_unlock(&hash_table_lock);
spin_unlock(&lru_list_lock);
- return 1;
+ return 0;
busy_buffer_page:
/* Uhhuh, start writeback so that we don't end up with all dirty pages */
@@ -2428,6 +2429,7 @@
goto cleaned_buffers_try_again;
}
wakeup_bdflush(0);
+ return 1;
}
return 0;
}
diff --exclude-from=/home/marcelo/exclude -Nur linux.orig/mm/vmscan.c linux/mm/vmscan.c
--- linux.orig/mm/vmscan.c Thu Mar 1 19:21:08 2001
+++ linux/mm/vmscan.c Thu Mar 1 19:35:51 2001
@@ -269,7 +269,7 @@
return nr < SWAP_MIN ? SWAP_MIN : nr;
}
-static int swap_out(unsigned int priority, int gfp_mask)
+static int swap_out(unsigned int priority, int gfp_mask, int user)
{
int counter;
int retval = 0;
@@ -280,7 +280,12 @@
retval = swap_out_mm(mm, swap_amount(mm));
/* Then, look at the other mm's */
- counter = (mmlist_nr << SWAP_SHIFT) >> priority;
+
+ if (user)
+ counter = (mmlist_nr) >> priority;
+ else
+ counter = (mmlist_nr << SWAP_SHIFT) >> priority;
+
do {
struct list_head *p;
@@ -535,7 +540,7 @@
* buffer pages
*/
if (page->buffers) {
- int wait, clearedbuf;
+ int wait;
/*
* Since we might be doing disk IO, we have to
* drop the spinlock and take an extra reference
@@ -554,7 +559,8 @@
wait = 0; /* No IO */
/* Try to free the page buffers. */
- clearedbuf = try_to_free_buffers(page, wait);
+ if (try_to_free_buffers(page, wait))
+ flushed_pages++;
/*
* Re-take the spinlock. Note that we cannot
@@ -564,10 +570,8 @@
spin_lock(&pagemap_lru_lock);
/* The buffers were not freed. */
- if (!clearedbuf) {
+ if (page->buffers) {
add_page_to_inactive_dirty_list(page);
- if (wait)
- flushed_pages++;
/* The page was only in the buffer cache. */
} else if (!page->mapping) {
@@ -876,7 +880,7 @@
goto done;
/* If refill_inactive_scan failed, try to page stuff out.. */
- swap_out(DEF_PRIORITY, gfp_mask);
+ swap_out(DEF_PRIORITY, gfp_mask, user);
if (--maxtry <= 0)
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
OT: UCITA in Oregon
Sorry for the off-topic message, but this will be of interest to some here. There are a couple of bills being proposed in the Oregon legislature. One to stop UCITA and one to adopt it. (For those of you not familiar with UCITA, it is a nasty little provision being pushed that would make click-thru licences and all the other variants binding, as well as outlawing reverse engineering and other things.) More info on it can be found at: http://www.ieee.org/organizations/pubs/newsletters/npss/june2000/position.ht m and http://www.ieeeusa.org/forum/grassroots/ucita/ It turns out the person who has sponsored the bill to enact UCITA into law is the head of the Judiciary committee, so this could get interesting. If you are interested in testifying against UCITA contact Damon Elder at [EMAIL PROTECTED] He is the intern for Representative Phil Barnhart. Thanks! --- | Terrorists - The Boogiemen for a new Millennium. | |"The moral PGP Diffie taught Zimmermann unites all| Disclaimer: | | mankind free in one-key-steganography-privacy!" | Ignore the man | | | behind the keyboard.| | http://www.ctrl-alt-del.com/~alan/ |[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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
Alan Cox <[EMAIL PROTECTED]> writes: > > Why not use kernel/pm.c:pm_register? Then you can either refuse > > suspend or have a proper workaround. > > Feel free to provide code. You have me there - I should have realised who I was writing to ;-) [...] > I dont have the hardware I neither. -- http://www.penguinpowered.com/~vii - 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: NETDEV WATCHDOG: eth0: transmit timed out
Caleb Epstein wrote: > > I am seeing the following error after my machine has been up > for a while. My eth0 is connected to a switched, local > subnet. There is not a lot of traffic on the interface, maybe > a few 100 Mbytes or so. Taking the interface down and then up > again fixes the problem (until it happens again :) > > Here is the relevant section from my kernel log > > Mar 1 10:48:44 tela kernel: NETDEV WATCHDOG: eth0: transmit timed out My guess would be that the driver has decided there's no link beat on the 10baseT interface and has flopped over to using 10base2. A fix for this exists in 2.4.2-ac5+, in the zerocopy patch and in http://www.uow.edu.au/~andrewm/linux/3c59x.c-2.4.2-pre4.gz but not in 2.4.2. You'll need to use options 3c59x options=0 in /etc/modules.conf to pin the driver down to using a particular physical interface - disable autoselection. So could you please upgrade the driver? If problems remain, please send me a report, as described in the final section of Documentation/networking/vortex.txt. Thanks. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] oom-killer trigger
> > 1. the OOM killer never triggers if we have > freepages.min >of free memory > 2. __alloc_pages() never allocates pages to < freepages.min >for user allocations > > ==> the OOM killer never gets triggered under some workloads; > the system just sits around with nr_free_pages == freepages.min > > The patch below trivially fixes this by upping the OOM kill limit > by a really small number of pages ... > + if (nr_free_pages() > freepages.min + 4) Call me stupid, but why not just change the > to >= (or < to <=) rather than introducing a magic number (4). Or at least make the magic number interesting, like: + if (nr_free_pages() > freepages.min + 42) :-) Thanks for the bugfix, David -- David Mansfield (718) 963-2020 [EMAIL PROTECTED] Ultramaster Group, LLC www.ultramaster.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][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Chris Evans wrote: > On Thu, 1 Mar 2001, Rik van Riel wrote: > > > True. I think we want something in-between our ideas... > ^^^ > > a while. This should make it possible for the disk reads to > ^^ > > Oh dear.. not more "vm design by waving hands in the air". Come > on people, improve the vm by careful profiling, tweaking and > benching, not by throwing random patches in that seem cool in > theory. Actually, this was more of "vm design by looking at what the FreeBSD folks did, why it didn't work and how they fixed it after 2 years of testing various things". 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][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Chris Evans wrote: > > On Thu, 1 Mar 2001, Rik van Riel wrote: > > > True. I think we want something in-between our ideas... > ^^^ > > a while. This should make it possible for the disk reads to > ^^ > > Oh dear.. not more "vm design by waving hands in the air". Come on people, > improve the vm by careful profiling, tweaking and benching, not by > throwing random patches in that seem cool in theory. OTOH, "careful profiling, tweaking and benching" are always limited to a number workloads. - 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.2ac7
> > Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium II= > I > > correctly detected on, at least, 2.2.18, 2.4.2 and 2.4.2-ac4. The > > processor is a 600 MHz one, with a 133 MHz front bus. The model name printing has not changed. Not at all. > same here with PIII550MHz/100MHz bus. Actually, it is wrong in 2.4.2-ac6 > as well -- don't know about ac5: Please send me the value of your 0x2A MTRR. Because this isnt properly intel documented there is a certain amount of research still required. 363 / 66 would be a 66Mhz bus 5.5 multiplier. It got the multiplier right but it appears the bus speed encoding may be different. - 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][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Rik van Riel wrote: > True. I think we want something in-between our ideas... ^^^ > a while. This should make it possible for the disk reads to ^^ Oh dear.. not more "vm design by waving hands in the air". Come on people, improve the vm by careful profiling, tweaking and benching, not by throwing random patches in that seem cool in theory. Cheers 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/
[PATCH] oom-killer trigger
Hi,
the OOM killer in Linux 2.4 has a rather embarrasing bug.
1. the OOM killer never triggers if we have > freepages.min
of free memory
2. __alloc_pages() never allocates pages to < freepages.min
for user allocations
==> the OOM killer never gets triggered under some workloads;
the system just sits around with nr_free_pages == freepages.min
The patch below trivially fixes this by upping the OOM kill limit
by a really small number of pages ...
Now lets hope it won't trigger too early (but since it'll only
trigger when we're completely out of swap, etc...).
regards,
Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...
http://www.surriel.com/
http://www.conectiva.com/ http://distro.conectiva.com/
--- mm/oom_kill.c.orig Thu Mar 1 18:57:11 2001
+++ mm/oom_kill.c Thu Mar 1 18:58:23 2001
@@ -188,13 +188,17 @@
*
* Returns 0 if there is still enough memory left,
* 1 when we are out of memory (otherwise).
+ *
+ * Note that since __alloc_pages() never lets user
+ * allocations go below freepages.min, we have to
+ * use a slightly higher threshold here...
*/
int out_of_memory(void)
{
struct sysinfo swp_info;
/* Enough free memory? Not OOM. */
- if (nr_free_pages() > freepages.min)
+ if (nr_free_pages() > freepages.min + 4)
return 0;
if (nr_free_pages() + nr_inactive_clean_pages() > freepages.low)
-
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][rfc][rft] vm throughput 2.4.2-ac4
> Except that your code throws the random junk at the elevator all > the time, while my code only bothers the elevator every once in > a while. This should make it possible for the disk reads to > continue with less interruptions. Think about it this way, throwing the stuff at the I/O layer is saying 'please make this go away'. Thats the VM decision. Scheduling the I/O is an I/O and driver layer decision. - 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: ZF MachZ Watchdog driver
On Thu, Mar 01, 2001 at 07:37:46PM -0300, Fernando Fuganti wrote:
>
> Hi !
>
> This is the driver for the builtin watchdog device on the embedded MachZ
> processor made by ZFmicro. The patch is against 2.2.19pre16 and the
> driver is based on sbc60xxwdt.c.
>
I have a user-space daemon for driving the watchdog. I see it uses the
same user-space interface as sbc60xxwdt.c, except it can't be disabled :)
Did you write one too ?
Should we find somewhere to actually publish these watchdog-daemons ?
Or have I completely missed that there already is a place for these
daemons, and that there already exist publicly available daemons for
driving the sbc60xxwdt and ZFmicro ?
Btw. Alan, the documentation somehow got lost to the sbc60xxwdc driver
when you so kindly converted it to 2.4 - it's here below :)
--
: [EMAIL PROTECTED] : And I see the elder races, :
:.: putrid forms of man:
: Jakob Østergaard : See him rise and claim the earth, :
:OZ9ABN : his downfall is at hand. :
:.:{Konkhra}...:
diff -Nru linux/Documentation/Configure.help linux.loaded/Documentation/Configure.help
--- linux/Documentation/Configure.help Wed Apr 26 20:03:13 2000
+++ linux.loaded/Documentation/Configure.help Wed Apr 26 19:31:41 2000
@@ -9371,6 +9371,18 @@
module, say M here and read Documentation/modules.txt. Most people
will say N.
+SBC-60XX Watchdog Timer
+CONFIG_60XX_WDT
+ This driver can be used with the watchdog timer found on some
+ single board computers, namely the 6010 PII based computer.
+ It may well work with other cards. It reads port 0x443 to enable
+ and re-set the watchdog timer, and reads port 0x45 to disable
+ the watchdog. If you have a card that behave in similar ways,
+ you can probably make this driver work with your card as well.
+
+ You can compile this driver directly into the kernel, or use
+ it as a module. The module will be called sbc60xxwdt.o.
+
Enhanced Real Time Clock Support
CONFIG_RTC
If you say Y here and create a character special file /dev/rtc with
-
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][rfc][rft] vm throughput 2.4.2-ac4
> There is no mechanysm in place that ensures that dirty pages can't > get out of control, and they do in fact get out of control, and it > is exaserbated (mho) by attempting to define 'too much I/O' without > any information to base this definition upon. I think this is a good point. If you do 'too much I/O' then the I/O gets throttled by submit_bh(). The block I/O layer knows about 'too much I/O'. - 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 IO problem on multiple PCI busses
> There is no 'fake' ISA bus number you need. There is a 'real' one, > the one on which the PCI-->ISA bridge lives, why not use that one > :-) IFF the ISA bus hangs off the PCI bridge. Similarly not all machines have PCI as the primary I/O bus. On hppa PCI busses hang off the gsc bus - 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: APM suspend system lockup under 2.4.2 and 2.4.2ac1
> Why not use kernel/pm.c:pm_register? Then you can either refuse > suspend or have a proper workaround. Feel free to provide code. I suspect you can do something like refuse to suspend if the device is open at all and reload the firmware, reinit it on resume if it was idle. I dont have the hardware - 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][rfc][rft] vm throughput 2.4.2-ac4
Rik van Riel wrote:
[ ... ]
> Except that your code throws the random junk at the elevator all
> the time, while my code only bothers the elevator every once in
> a while. This should make it possible for the disk reads to
> continue with less interruptions.
>
Couldn't agree with you more. The elevator does a decent job
these days, but higher level clustering could do more ...
[ ...]
> Indeed. IMHO we should fix this by putting explicit IO
> clustering in the ->writepage() functions.
Enhancing writepage() to perform clustering is the first step.
In addition you want entities (kupdated, kswapd, et. al)
that currently work with only buffers to invoke writepage()
at appropriate points. Just today I sent a patch that does this
and also combines delayed allocation out to Al Viro for comments.
If anyone else is interested I can send it out to the list.
ananth.
--
Rajagopal Ananthanarayanan ("ananth")
Member Technical Staff, SGI.
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Q: explicit alignment control for the slab allocator
Mark Hemment wrote: > > On Thu, 1 Mar 2001, Manfred Spraul wrote: > > > Mark Hemment wrote: > > > > > > The original idea behind offset was for objects with a "hot" area > > > greater than a single L1 cache line. By using offset correctly (and to my > > > knowledge it has never been used anywhere in the Linux kernel), a SLAB > > > cache creator (caller of kmem_cache_create()) could ask the SLAB for more > > > than one colour (space/L1 cache lines) offset between objects. > > > > > > > What's the difference between this definition of 'offset' and alignment? > > The positioning of the first object within a slab (at least that is how > it is suppose to work). > > The distance between all objects within a slab is constant, so the > colouring of objects depends upon the cache line (offset) the first object > is placed on. > The alignment is the boundary objects fall upon within a slab. This may > require 'padding' between the objects so they fall on the correct > boundaries (ie. they aren't a 'natural' size). > For kmem_cache_create(), a zero offset means the offset is the same as > the alignment. > > Take the case of offset being 64, and alignment being 32. > Here, the allocator attempts to place the first object on a 64byte > boundary (say, at offset 0), and all subsequent objects (within the same > cache) on a 32byte boundary. > Now, when it comes to construct the next slab, it tries to place the > first object 64bytes offset from the first object in the previous > slab (say, at offset 64). The distance between the objects is still the > same - ie. they fall on 32byte boundaries. > > See the difference? > Yes, I see the difference, but I'm not sure that it will work as intended. offset must be a multiple of the alignment, everything else won't work. In which cases an offset > alignment is really a win? Obviously using offset 32 bytes for a structure with a 64 byte hot zone means that 2 slabs with a different "color" compete for the same cache lines [just assuming 32 byte cache lines for simplicity] in 50% of the cases, but otoh offset==64 halfs the number of possible colors. -- Manfred - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4: Next Generation Kernel Security
Hi, We at linuxsecurity.com just released an article on the new security features of the 2.4 kernel, and thought the kernel list would be interested. "This document outlines the kernel security improvements that have been made in the 2.4 kernel. A number of significant improvements including cryptography and access control make 2.4 a serious contender for secure corporate environments as well as private virtual networking." http://www.linuxsecurity.com/feature_stories/kernel-24-security.html Recently we also released another document outlining the packet filtering/mangling abilities in the new netfilter that might also be of interest: Linux Kernel 2.4 Firewalling Matures: netfilter http://www.linuxsecurity.com/feature_stories/kernel-netfilter.html Best, Dave Wreski - 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/
ZF MachZ Watchdog driver
Hi !
This is the driver for the builtin watchdog device on the embedded MachZ
processor made by ZFmicro. The patch is against 2.2.19pre16 and the
driver is based on sbc60xxwdt.c.
Fernando Fuganti
diff -Nru linux-2.2.19pre16.orig/Documentation/Configure.help
linux-2.2.19pre16/Documentation/Configure.help
--- linux-2.2.19pre16.orig/Documentation/Configure.help Thu Mar 1 12:44:09 2001
+++ linux-2.2.19pre16/Documentation/Configure.help Thu Mar 1 17:21:36 2001
@@ -10535,6 +10535,19 @@
You can compile this driver directly into the kernel, or use
it as a module. The module will be called sbc60xxwdt.o.
+ZF MachZ Watchdog
+CONFIG_MACHZ_WDT
+ If you are using a ZF Micro MachZ processor, say Y here, otherwise N.
+ This is the driver for the watchdog timer builtin on that processor
+ using ZF-Logic interface. This watchdog simply watches your kernel to
+ make sure it doesn't freeze, and if it does, it reboots your computer
+ after a certain amount of time.
+
+ This driver is also available as a module ( = code which can be
+ inserted in and removed from the running kernel whenever you want).
+ The module is called machzwd.o. If you want to compile it as a module,
+ say M here and read Documentation/modules.txt.
+
CONFIG_MICROCODE
/dev/cpu/microcode - Intel IA32 CPU microcode support
diff -Nru linux-2.2.19pre16.orig/drivers/char/Config.in
linux-2.2.19pre16/drivers/char/Config.in
--- linux-2.2.19pre16.orig/drivers/char/Config.in Thu Mar 1 12:44:11 2001
+++ linux-2.2.19pre16/drivers/char/Config.inThu Mar 1 17:21:36 2001
@@ -114,6 +114,7 @@
fi
fi
tristate ' WDT PCI Watchdog timer' CONFIG_WDTPCI
+ tristate ' ZF MachZ Watchdog' CONFIG_MACHZ_WDT
endmenu
fi
diff -Nru linux-2.2.19pre16.orig/drivers/char/Makefile
linux-2.2.19pre16/drivers/char/Makefile
--- linux-2.2.19pre16.orig/drivers/char/MakefileThu Mar 1 12:44:11 2001
+++ linux-2.2.19pre16/drivers/char/Makefile Thu Mar 1 17:21:36 2001
@@ -367,6 +367,14 @@
endif
endif
+ifeq ($(CONFIG_MACHZ_WDT),y)
+O_OBJS += machzwd.o
+else
+ ifeq ($(CONFIG_MACHZ_WDT),m)
+M_OBJS += machzwd.o
+ endif
+endif
+
ifeq ($(CONFIG_RTC),y)
O_OBJS += rtc.o
endif
diff -Nru linux-2.2.19pre16.orig/drivers/char/machzwd.c
linux-2.2.19pre16/drivers/char/machzwd.c
--- linux-2.2.19pre16.orig/drivers/char/machzwd.c Wed Dec 31 21:00:00 1969
+++ linux-2.2.19pre16/drivers/char/machzwd.cThu Mar 1 17:21:36 2001
@@ -0,0 +1,545 @@
+/*
+ * MachZ ZF-Logic Watchdog Timer driver for Linux
+ *
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * The author does NOT admit liability nor provide warranty for
+ * any of this software. This material is provided "AS-IS" in
+ * the hope that it may be useful for others.
+ *
+ * Author: Fernando Fuganti <[EMAIL PROTECTED]>
+ *
+ * Based on sbc60xxwdt.c by Jakob Oestergaard
+ *
+ *
+ * We have two timers (wd#1, wd#2) driven by a 32 KHz clock with the
+ * following periods:
+ * wd#1 - 2 seconds;
+ * wd#2 - 7.2 ms;
+ * After the expiration of wd#1, it can generate a NMI, SCI, SMI, or
+ * a system RESET and it starts wd#2 that unconditionaly will RESET
+ * the system when the counter reaches zero.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+/* ports */
+#define ZF_IOBASE 0x218
+#define INDEX 0x218
+#define DATA_B 0x219
+#define DATA_W 0x21A
+#define DATA_D 0x21A
+
+/* indexes */ /* size */
+#define ZFL_VERSION0x02/* 16 */
+#define CONTROL0x10/* 16 */
+#define STATUS 0x12/* 8*/
+#define COUNTER_1 0x0C/* 16 */
+#define COUNTER_2 0x0E/* 8*/
+#define PULSE_LEN 0x0F/* 8*/
+
+/* controls */
+#define ENABLE_WD1 0x0001
+#define ENABLE_WD2 0x0002
+#define RESET_WD1 0x0010
+#define RESET_WD2 0x0020
+#define GEN_SCI0x0100
+#define GEN_NMI0x0200
+#define GEN_SMI0x0400
+#define GEN_RESET 0x0800
+
+
+/* utilities */
+
+#define WD10
+#define WD21
+
+#define zf_writew(port, data) { outb(port, INDEX); outw(data, DATA_W); }
+#define zf_writeb(port, data) { outb(port, INDEX); outb(data, DATA_B); }
+#define zf_get_ZFL_version() zf_readw(ZFL_VERSION)
+
+
+static unsigned short zf_readw(unsigned char port)
+{
+ outb(port, INDEX);
+ return inw(DATA_W);
+}
+
+static unsigned short zf_readb(unsig
Re: [CFT][PATCH] Re: fat problem in 2.4.2
Hi, On Thu, 1 Mar 2001, Alexander Viro wrote: > IOW, if it's worth doing at all it probably should be > on expanding path in vmtruncate() - limit checks are already > done, but old i_size is still not lost... The fs where it's important have mmu_private, that's what I use to decide whether to expand or truncate. bye, Roman - 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: Hashing and directories
H. Peter Anvin writes [re hashed directories]: > I don't see there being any fundamental reason to not do such an > improvement, except the one Alan Cox mentioned -- crash recovery -- > (which I think can be dealt with; in my example above as long as the leaf > nodes can get recovered, the tree can be rebuilt. Actually, with Daniel's implementation, the index blocks will be in the same file as the directory leaf nodes, so there should be no problem in losing leaf blocks after a crash (not more so than the current ext2 setup). Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
Before I reply: I apologise for starting this argument, or at least making it worse, and please let me say again that I really would like to see improvements in directory searching etc. ... my original point was simply a half-joking aside to the effect that we should not encourage people to put thousands of files in a single directory ... "H. Peter Anvin" wrote: > > * userland issues (what, you thought that limits on the > > command size will go away?) > Last I checked, the command line size limit wasn't a userland issue, but > rather a limit of the kernel exec(). This might have changed. Actually this is also a serious problem. We have a ticketing system at work that stores all its data in files in large directories, and I discovered recently that I can only pass about a tenth of the current file names on a command line. Yes, we have xargs, but ... Also (this happens to be Solaris on a 8 x 40MHz Sparc system) there is a significant delay just to read the directory. > > * portability Also an issue. Fortunately we store a lot of data on NetApps, so the performance of the filesystem as such is less of an issue; but, that means the size of the data transfer across the network involved in reading a directory can become an issue too. > > The point being: applications and users _do_ know better what structure > > is there. Kernel can try to second-guess them and be real good at that, but > > inability to second-guess is the last of the reasons why aforementioned > > strategies are used. All good points ... > However, there are issues where users and applications don't want to > structure their namespace for the convenience of the kernel, for good or > bad reasons. But there are other reasons (besides the kernel's and filesystems' handling of directories and name lookups). I think you're spot on about the performance issues and on-disk structures, though. > -hpa -- /* Bill Crawford, Unix Systems Developer, ebOne, formerly GTS Netcom */ #include "stddiscl.h" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
Alexander Viro wrote: > > I _really_ don't want to trust the ability of shell to deal with long > command lines. I also don't like the failure modes with history expansion > causing OOM, etc. > > AFAICS right now we hit the kernel limit first, but I really doubt that > raising said limit is a good idea. > Arbitrary limits are generally bad. Yes, using a very long command line is usually a bad idea, but there are cases for which it is the only reasonable way to do something. Categorically blocking them is not a good idea either. > xargs is there for purpose... Well, yes; using xargs is a good idea, not the least because it enables some parallelism that wouldn't otherwise be there. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hashing and directories
On Thu, 1 Mar 2001, H. Peter Anvin wrote: > > * userland issues (what, you thought that limits on the > > command size will go away?) > > Last I checked, the command line size limit wasn't a userland issue, but > rather a limit of the kernel exec(). This might have changed. I _really_ don't want to trust the ability of shell to deal with long command lines. I also don't like the failure modes with history expansion causing OOM, etc. AFAICS right now we hit the kernel limit first, but I really doubt that raising said limit is a good idea. xargs is there for purpose... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: What is 2.4 Linux networking performance like compared to BSD?
At 07:03 PM 1/03/2001 +0300, Hans Reiser wrote: > > > They know that iMimic's polymix performance on Linux 2.2.* is half > what it is on > > > BSD. Has the Linux 2.4 networking code caught up to BSD? > > > > > > Can I tell them not to worry about the Linux networking code > strangling their > > > webcache product's performance, or not? Hans, if iMimic's polygraph performance is "half" on linux versus that of freebsd, then it is a sign that iMimic has some awful code and/or are doing something wrong in linux versus freebsd. >The problem is that I really need BSD vs. Linux experiences, not Linux 2.4 vs. >2.2 experiences, because the webcache industry tends to strongly disparage >Linux >networking code, so much better isn't necessarily good enough. please stop generalizing. there is at least one vendor in the webcache industry that is more than happy with the linux networking code. cheers, lincoln. - 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.2ac7
On Thu, 1 Mar 2001, José Luis Domingo López wrote: > Linux 2.4.2-ac7 reports wrong CPU speed and model name for a Pentium III > correctly detected on, at least, 2.2.18, 2.4.2 and 2.4.2-ac4. The > processor is a 600 MHz one, with a 133 MHz front bus. same here with PIII550MHz/100MHz bus. Actually, it is wrong in 2.4.2-ac6 as well -- don't know about ac5: here is info from bootlog: NT 05 Int: type 0, pol 0, trig 0, bus 3, IRQ 06, APIC ID 2, APIC INT 06 Int: type 0, pol 0, trig 0, bus 3, IRQ 07, APIC ID 2, APIC INT 07 Int: type 0, pol 1, trig 1, bus 3, IRQ 08, APIC ID 2, APIC INT 08 Int: type 0, pol 0, trig 0, bus 3, IRQ 09, APIC ID 2, APIC INT 09 Int: type 0, pol 0, trig 0, bus 3, IRQ 0a, APIC ID 2, APIC INT 0a Int: type 0, pol 0, trig 0, bus 3, IRQ 0b, APIC ID 2, APIC INT 0b Int: type 0, pol 0, trig 0, bus 3, IRQ 0c, APIC ID 2, APIC INT 0c Int: type 0, pol 0, trig 0, bus 3, IRQ 0d, APIC ID 2, APIC INT 0d Int: type 0, pol 0, trig 0, bus 3, IRQ 0e, APIC ID 2, APIC INT 0e Int: type 0, pol 0, trig 0, bus 3, IRQ 0f, APIC ID 2, APIC INT 0f Int: type 0, pol 3, trig 3, bus 0, IRQ 24, APIC ID 2, APIC INT 11 Int: type 0, pol 3, trig 3, bus 0, IRQ 28, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 29, APIC ID 2, APIC INT 12 Int: type 0, pol 3, trig 3, bus 0, IRQ 30, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 1, IRQ 00, APIC ID 2, APIC INT 10 Int: type 0, pol 3, trig 3, bus 2, IRQ 10, APIC ID 2, APIC INT 13 Int: type 0, pol 3, trig 3, bus 2, IRQ 14, APIC ID 2, APIC INT 10 Int: type 2, pol 3, trig 1, bus 3, IRQ 00, APIC ID 2, APIC INT 17 Lint: type 3, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 00 Lint: type 1, pol 0, trig 0, bus 0, IRQ 00, APIC ID ff, APIC LINT 01 Processors: 2 mapped APIC to e000 (fee0) mapped IOAPIC to d000 (fec0) Kernel command line: auto BOOT_IMAGE=242-ac6 ro root=341 BOOT_FILE=/boot/vmlinuz-2.4.2-ac6 video=matrox:vesa:0x118 parport=0x378,7 console=ttyS1,38400 console=tty0 nmi_watchdog=0 Initializing CPU#0 Detected 548.547 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1094.45 BogoMIPS Memory: 1026616k/1048512k available (1855k kernel code, 21508k reserved, 477k data, 248k init, 131008k highmem) Dentry-cache hash table entries: 131072 (order: 8, 1048576 bytes) Buffer-cache hash table entries: 65536 (order: 6, 262144 bytes) Page-cache hash table entries: 262144 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.37 (20001109) Richard Gooch ([EMAIL PROTECTED]) mtrr: detected mtrr type: Intel CPU: Before vendor init, caps: 0383fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383fbff CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff CPU0: Intel Pentium III (Katmai) stepping 03 per-CPU timeslice cutoff: 1462.42 usecs. Getting VERSION: 40011 Getting VERSION: 40011 Getting ID: 0 Getting ID: f00 Getting LVT0: 700 Getting LVT1: 400 enabled ExtINT on CPU#0 ESR value before enabling vector: ESR value after enabling vector: CPU present map: 3 Booting processor 1/1 eip 2000 Setting warm reset code and vector. 1. 2. 3. Asserting INIT. Waiting for send to finish... +Deasserting INIT. Waiting for send to finish... +#startup loops: 2. Sending STARTUP #1. After apic_write. Initializing CPU#1 Startup point 1. CPU#1 (phys ID: 1) waiting for CALLOUT Waiting for send to finish... +Sending STARTUP #2. After apic_write. Startup point 1. Waiting for send to finish... +After Startup. Before Callout 1. After Callout 1. CALLIN, before setup_local_APIC(). masked ExtINT on CPU#1 ESR value before enabling vector: ESR value after enabling vector: Calibrating delay loop... 1094.45 BogoMIPS Stack at about c221dfbc CPU: Before vendor init, caps: 0387fbff , vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU speed 363Mhz, Bus Speed 66MHz Intel machine check reporting enabled on CPU#1. CPU: After vendor init, caps: 0387fbff CPU serial number disabled. CPU: After generic, caps: 0383fbff CPU: Common caps: 0383fbff 0
Re: Unmounting and ejecting the root fs on shutdown.
Per Erik Stendahl wrote: > > Nah, that looks too easy! ;-) > > > This might save everyone some pain: > > from hdparm(8) man page (mine has some format > > bugs, but you get the picture) > > > Is it true that the root fs is left mounted read-only? What is the > rationale behind this? It seems to me that it would be better to > completely unmount it and do whatever cleaning up is required (like > cdrom_release()?). But I've been known to miss important issues before! > :-) > > BTW, what would be the best way to determine which devices are cdrom > devices? Looks like /proc/sys/dev/cdrom/info could be of use but what > happens on a computer with more than one cdrom device? > Read about devfs option in 2.4 kernel. it puts only devices that exist into /dev/cdroms/cdrom0, dev/cdroms/cdrom1, etc. and if hdparm works (and it must since redhat's installer ejects it's cd when rebooting) and you still are looking for a solution, well no comment. - 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: i2o & Promise SuperTrak100
On Wed, 28 Feb 2001, Andrew Morton wrote: > This untested patch should fix the scheduling-in-interrupt > thing. > > > --- kernel/sys.c.orig Thu Mar 1 10:06:14 2001 > +++ kernel/sys.c Thu Mar 1 10:07:43 2001 > @@ -330,6 +330,12 @@ Yes, this fixed the oops. Now it's possible to ctrl-alt-del reboot when i2o_block hangs. It still happens four times out of five reboots meaning it is intermittent. (Timing as Alan mentioned - goes away when DEBUG enabled) I have to put in some better HD's and test stability of the filesystem on this device. Any suggestions what's best way to do it to get some meaningful results? Thanks David - 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: New net features for added performance
> "Jeff" == Jeff Garzik <[EMAIL PROTECTED]> writes: Jeff> 1) Rx Skb recycling. It would be nice to have skbs returned to Jeff> the driver after the net core is done with them, rather than Jeff> have netif_rx free the skb. Many drivers pre-allocate a number Jeff> of maximum-sized skbs into which the net card DMA's data. If Jeff> netif_rx returned the SKB instead of freeing it, the driver Jeff> could simply flip the DescriptorOwned bit for that buffer, Jeff> giving it immediately back to the net card. Jeff> Advantages: A de-allocation immediately followed by a Jeff> reallocation is eliminated, less L1 cache pollution during Jeff> interrupt handling. Potentially less DMA traffic between card Jeff> and host. Jeff> Disadvantages? I already tried this with the AceNIC GigE driver some time ago, and after Ingo came up with a per-CPU slab patch the gain was gone. I am not sure the complexity is worth it. Jes - 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][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Mike Galbraith wrote: > On Thu, 1 Mar 2001, Rik van Riel wrote: > > On Thu, 1 Mar 2001, Mike Galbraith wrote: > No no no and again no (perhaps I misread that bit). But otoh, > you haven't tested the patch I sent in good faith. I sent it > because I have thought about it. I may be wrong in my > interpretation of the results, but those results were thought > about.. and they exist. I haven't tested it yet for a number of reasons. The most important one is that the FreeBSD people have been playing with this thing for a few years now and Matt Dillon has told me the result of their tests ;) > > But if the amount of dirtied pages is _small_, it means that we can > > allow the reads to continue uninterrupted for a while before we > > flush all dirty pages in one go... > > "If wishes were horses, beggers would ride." > > There is no mechanysm in place that ensures that dirty pages > can't get out of control, and they do in fact get out of > control, and it is exaserbated (mho) by attempting to define > 'too much I/O' without any information to base this definition > upon. True. I think we want something in-between our ideas... > > Also, the elevator can only try to optimise whatever you throw at > > it. If you throw random requests at the elevator, you cannot expect > > it to do ANY GOOD ... > > This is a very good point (which I will think upon). I ask you this > in return. Why do you think that the random junk you throw at the > elevator is different than the random junk I throw at it? ;-) I see > no difference at all.. it's the same exact junk. Except that your code throws the random junk at the elevator all the time, while my code only bothers the elevator every once in a while. This should make it possible for the disk reads to continue with less interruptions. > > The merging at the elevator level only works if the requests sent to > > it are right next to each other on disk. This means that randomly > > sending stuff to disk really DOES DESTROY PERFORMANCE and there's > > nothing the elevator could ever hope to do about that. > > True to some (very real) extent because of the limited buffering > of requests. However, I can not find any useful information > that the vm is using to guarantee the IT does not destroy > performance by your own definition. Indeed. IMHO we should fix this by putting explicit IO clustering in the ->writepage() functions. Doing this, in combination with *WAITING* for dirty pages to accumulate on the inactive list will give us the possibility to do more writeout of dirty data with less disk seeks (and less slowdown of the reads). 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: Hashing and directories
On Thu, 1 Mar 2001, Alexander Viro wrote: > * userland issues (what, you thought that limits on the > command size will go away?) the space allowed for arguments is not a userland issue, it is a kernel limit defined by MAX_ARG_PAGES in binfmts.h, so one could tweak it if one wanted to without breaking any userland. Regards, Tigran - 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: Hashing and directories
Alexander Viro wrote: > > > > Yes -- because their workaround kernel slowness. > > Pavel, I'm afraid that you are missing the point. Several, actually: > * limits of _human_ capability to deal with large unstructured > sets of objects Not an issue if you're a machine. > * userland issues (what, you thought that limits on the > command size will go away?) Last I checked, the command line size limit wasn't a userland issue, but rather a limit of the kernel exec(). This might have changed. > * portability > The point being: applications and users _do_ know better what structure > is there. Kernel can try to second-guess them and be real good at that, but > inability to second-guess is the last of the reasons why aforementioned > strategies are used. However, there are issues where users and applications don't want to structure their namespace for the convenience of the kernel, for good or bad reasons. There are structures which are known to produce vastly better performance even in the not-very-uncommon cases, although of course they provide dramatic improvements in the extreme. I personally happen to like the hash-indexed B-tree because of their extremely high fanout and because they don't impose any penalty in the other extreme (if your directory is small enough to fit in a single block, you skip the B-tree and have the linear non-hash leaf node only) but there are other structures which work as well. I don't see there being any fundamental reason to not do such an improvement, except the one Alan Cox mentioned -- crash recovery -- (which I think can be dealt with; in my example above as long as the leaf nodes can get recovered, the tree can be rebuilt. Consider starting each leaf node block with a magic and a pointer to its home inode; combined with a leaf node block count in the home inode, that should be quite robust.) It would be particularly nice to implement this more as an enhancement to ext3 than ext2, even though the issue is orthogonal, since ext3 should add a layer of inherent integrity protection. -hpa -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [CFT][PATCH] Re: fat problem in 2.4.2
On Thu, 1 Mar 2001, Roman Zippel wrote:
> Hi,
>
> On Thu, 1 Mar 2001, Alexander Viro wrote:
>
> > +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> > +{
> > + struct page *page;
> > + unsigned long index, offset;
> > + int err;
> > +
> > + if (!mapping->a_ops->prepare_write || !mapping->a_ops->commit_write)
> > + return -ENOSYS;
> > +
> > + offset = (size & (PAGE_CACHE_SIZE-1)); /* Within page */
> > + index = size >> PAGE_CACHE_SHIFT;
>
> For affs I did basically the same with a small difference:
>
> offset = ((size-1) & (PAGE_CACHE_SIZE-1)) + 1;
> index = (size-1) >> PAGE_CACHE_SHIFT;
>
> That works fine here and allocates a page in the cache more likely to be
> used.
The only difference is in the case when size is a multiple of
PAGE_CACHE_SHIFT, so most of the time it's the same, but yeah, this
variant is probably nicer.
The problem with putting it into ->truncate() is obvious -
handling errors. And doing the thing before vmtruncate() (in
foo_notify_change(), whatever) is also PITA - you need to
reproduce the rlimit handling. Not nice...
IOW, if it's worth doing at all it probably should be
on expanding path in vmtruncate() - limit checks are already
done, but old i_size is still not lost...
Cheers,
Al
-
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/
NBD blocksizes!=1024
Here is simple fix (against 2.4.2, but can be easily applied to 2.2.18 too) for NBD, OKed by Pavel. It allows to use blocksizes other than 1024 bytes. Without this fix, device with 4096-byte blocks has only 1/8 part accessible (and thus mke2fs fails, etc.). To use NBD with variable blocksizes, you'll need updated nbd-client.c - Pavel should already have it in CVS, if not, take that from archive linked at http://fortunedirectory.com/aga/NBDServer.html (there is also my NBD server that stores and uses NBD device content compressed with ZLIB - on my current /usr/src, disk space usage is about fourfold smaller). BTW, I've noticed quite a bit of speedup while using blocks 4096 bytes long, instead of 1024. I'd like to hear if you notice/measure the same thing. === --- linux/drivers/block/nbd.c.OLD Mon Feb 26 22:27:52 2001 +++ linux/drivers/block/nbd.c Tue Feb 27 09:45:57 2001 @@ -18,6 +18,8 @@ * 97-9-13 Cosmetic changes * 98-5-13 Attempt to make 64-bit-clean on 64-bit machines * 99-1-11 Attempt to make 64-bit-clean on 32-bit machines <[EMAIL PROTECTED]> + * 01-2-27 Fix to store proper blockcount for kernel (calculated using + * BLOCK_SIZE_BITS, not device blocksize) <[EMAIL PROTECTED]> * * possible FIXME: make set_sock / set_blksize / set_size / do_it one syscall * why not: would need verify_area and friends, would share yet another @@ -413,16 +415,16 @@ nbd_blksize_bits[dev]++; temp >>= 1; } - nbd_sizes[dev] = nbd_bytesizes[dev] >> nbd_blksize_bits[dev]; - nbd_bytesizes[dev] = nbd_sizes[dev] << nbd_blksize_bits[dev]; + nbd_bytesizes[dev] &= ~(nbd_blksizes[dev]-1); + nbd_sizes[dev] = nbd_bytesizes[dev] >> BLOCK_SIZE_BITS; return 0; case NBD_SET_SIZE: - nbd_sizes[dev] = arg >> nbd_blksize_bits[dev]; - nbd_bytesizes[dev] = nbd_sizes[dev] << nbd_blksize_bits[dev]; + nbd_bytesizes[dev] = arg & ~(nbd_blksizes[dev]-1); + nbd_sizes[dev] = nbd_bytesizes[dev] >> BLOCK_SIZE_BITS; return 0; case NBD_SET_SIZE_BLOCKS: - nbd_sizes[dev] = arg; - nbd_bytesizes[dev] = ((u64) arg) << nbd_blksize_bits[dev]; + nbd_bytesizes[dev] = ((u64) arg) << nbd_blksize_bits[dev]; + nbd_sizes[dev] = nbd_bytesizes[dev] >> BLOCK_SIZE_BITS; return 0; case NBD_DO_IT: if (!lo->file) @@ -513,7 +515,7 @@ nbd_blksizes[i] = 1024; nbd_blksize_bits[i] = 10; nbd_bytesizes[i] = 0x7c00; /* 2GB */ - nbd_sizes[i] = nbd_bytesizes[i] >> nbd_blksize_bits[i]; + nbd_sizes[i] = nbd_bytesizes[i] >> BLOCK_SIZE_BITS; register_disk(NULL, MKDEV(MAJOR_NR,i), 1, &nbd_fops, nbd_bytesizes[i]>>9); } Alexey[Team OS/2] - 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: [CFT][PATCH] Re: fat problem in 2.4.2
Hi,
On Thu, 1 Mar 2001, Alexander Viro wrote:
> +static int generic_vm_expand(struct address_space *mapping, loff_t size)
> +{
> + struct page *page;
> + unsigned long index, offset;
> + int err;
> +
> + if (!mapping->a_ops->prepare_write || !mapping->a_ops->commit_write)
> + return -ENOSYS;
> +
> + offset = (size & (PAGE_CACHE_SIZE-1)); /* Within page */
> + index = size >> PAGE_CACHE_SHIFT;
For affs I did basically the same with a small difference:
offset = ((size-1) & (PAGE_CACHE_SIZE-1)) + 1;
index = (size-1) >> PAGE_CACHE_SHIFT;
That works fine here and allocates a page in the cache more likely to be
used.
bye, Roman
-
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: Hashing and directories
On Sat, 1 Jan 2000, Pavel Machek wrote: > Hi! > > > I was hoping to point out that in real life, most systems that > > need to access large numbers of files are already designed to do > > some kind of hashing, or at least to divide-and-conquer by using > > multi-level directory structures. > > Yes -- because their workaround kernel slowness. Pavel, I'm afraid that you are missing the point. Several, actually: * limits of _human_ capability to deal with large unstructured sets of objects * userland issues (what, you thought that limits on the command size will go away?) * portability The point being: applications and users _do_ know better what structure is there. Kernel can try to second-guess them and be real good at that, but inability to second-guess is the last of the reasons why aforementioned strategies are used. - 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: [CFT][PATCH] Re: fat problem in 2.4.2
On Thursday, March 01, 2001 12:05:50 PM -0800 Linus Torvalds <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Alexander Viro <[EMAIL PROTECTED]> wrote: >> >> Alan, fix is really quite simple. Especially if you have vmtruncate() >> returning int (ac1 used to do it, I didn't check later ones). Actually >> just a generic_cont_expand() done on expanding path in vmtruncate() >> will be enough - it should be OK for all cases, including normal >> filesystems. >> >> OK, any brave soul to test that? All I can promise that it builds. > > This looks like it would create a dummy block even for non-broken > filesystems (ie truncating a file to be larger on ext2 would create a > block, no?). While that would work, it would also waste disk-space. Another idea is to create the hole for new_file_size + [one block], and then truncate that block off the end of the file, leaving nothing but the hole. I'll never admit to suggesting it though. -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: Strange hdparm behaviour with Via 686b and 2.4.2
On Thu, Mar 01, 2001 at 05:00:07AM -0700, Harold Oga wrote: > Hi Nicholas, >I don't see a similar slowdown on my system. I have an Athlon 900 with > a MSI K7T Pro-2a motherboard and a 15Gig Maxtor 31536H2 5400 ATA100 HD. > This motherboard is a KT133 board, but it does also have a 686B chip. > Running the same steps you did, I get the following: > > [ogah@ogah /Junk]> ./dnetc -hide -nice 19 > [ogah@ogah /Junk]> sudo nice -n '-19' hdparm -m16 -tT /dev/hda > > /dev/hda: > setting multcount to 16 > multcount= 16 (on) > Timing buffer-cache reads: 128 MB in 0.70 seconds =182.86 MB/sec > Timing buffered disk reads: 64 MB in 2.41 seconds = 26.56 MB/sec > [ogah@ogah /Junk]> ./dnetc -shutdown > dnetc: 1 distributed.net client was shutdown. 0 failures. > [ogah@ogah /Junk]> sudo nice -n '-19' hdparm -m16 -tT /dev/hda > > /dev/hda: > setting multcount to 16 > multcount= 16 (on) > Timing buffer-cache reads: 128 MB in 0.67 seconds =191.04 MB/sec > Timing buffered disk reads: 64 MB in 2.42 seconds = 26.45 MB/sec > > One thing that comes to mind is that we are probably not using the same > version of the via82cxxx ide driver. I assume that you are using the > via82cxxx v3.20 driver that came with 2.4.2. You can check which version > of the via driver you are using by looking at /proc/ide/via. I am using > v4.3 of the via82cxxx driver which Vojtech Pavlik (the via82cxxx > maintainer) sent to the linux-kernel mailing list a while back. I have Yep I was. Couldn't find that particular message on the mailing list although I did find an earlier set. (See below.) Is there a central web location for these files? > attached the 2 files you need. Just copy the 2 files to > /usr/src/linux/drivers/ide/, replacing the versions that already exist in > that directory. That might fix your problems, as Vojtech fixed quite a > few bugs with regards to the 686b support between versions v3.20 and v4.3. > I know that for me, I was never able to get my ATA66 drive (hdb) to run at > full speed until driver v4.3. Until then, hda would get set correctly to > udma5, but hdb would get set to udma2 (ATA33) instead of udma4 (ATA66). First up, thanks for the help. I installed the two files you gave me, plus I added another file I found in archives: nic@thunder:~$ grep Id *.h *.c ide-timing.h: * $Id: ide-timing.h,v 2.1 2001/02/08 19:32:56 vojtech Exp $ amd7409.c: * $Id: amd7409.c,v 2.0 2001/02/08 21:08:60 vojtech Exp $ via82cxxx.c: * $Id: via82cxxx.c,v 4.3 2001/02/21 08:10:60 vojtech Exp $ amd7409.c was with: ide-timing.h: * $Id: ide-timing.h,v 2.0 2001/02/08 19:32:56 vojtech Exp $ via82cxxx.c: * $Id: via82cxxx.c,v 4.0 2001/02/08 19:32:60 vojtech Exp $ not sure if that would affect things. Anyway seems to have greater improved performance, but not without load on the system. Nic@thunder:~$ sudo nice -n '-19' hdparm -m16 -tT /dev/hda /dev/hda: setting multcount to 16 multcount= 16 (on) Timing buffer-cache reads: 128 MB in 0.78 seconds =164.10 MB/sec Timing buffered disk reads: 64 MB in 4.33 seconds = 14.78 MB/sec nic@thunder:~$ dnetc/dnetc -hide -nice 19 nic@thunder:~$ sudo nice -n '-19' hdparm -m16 -tT /dev/hda /dev/hda: setting multcount to 16 multcount= 16 (on) Timing buffer-cache reads: 128 MB in 0.80 seconds =160.00 MB/sec Timing buffered disk reads: 64 MB in 1.69 seconds = 37.87 MB/sec nic@thunder:~$ cat /proc/ide/via --VIA BusMastering IDE Configuration Driver Version: 4.3 South Bridge: VIA vt82c686b Revision: ISA 0x40 IDE 0x6 Highest DMA rate: UDMA100 BM-DMA base:0xe000 PCI clock: 34MHz Master Read Cycle IRDY:0ws Master Write Cycle IRDY:0ws BM IDE Status Register Read Retry: yes Max DRDY Pulse Width: No limit ---Primary IDE---Secondary IDE-- Read DMA FIFO flush: yes yes End Sector FIFO flush: no no Prefetch Buffer: yes yes Post Write Buffer:yes no Enabled: yes yes Simplex only: no no Cable Type: 80w 40w ---drive0drive1drive2drive3- Transfer Mode: UDMA PIO PIO PIO Address Setup: 29ns 116ns 116ns 116ns Cmd Active: 87ns 87ns 464ns 464ns Cmd Recovery:58ns 58ns 464ns 464ns Data Active: 87ns 319ns 319ns 319ns Data Recovery: 58ns 261ns 261ns 261ns Cycle Time: 20ns 580ns 580ns 580ns Transfer Rate: 100.0MB/s 3.4MB/s 3.4MB/s 3.4MB/s Here are some bonnie++ stats comparisions. With dnetc running: Version 1.00h --Sequential Output--
Re: Kernel is unstable
On Thu, Mar 01, 2001 at 11:04:55AM -0800, David S. Miller wrote: > Linus didn't find it to be such a gain, and in fact the one > place that does gain from such merging (sys_brk()) does the > merging by hand :-) somewhere in either kernel or glibc we need to do the merging to avoid allocating new vmas and to grow the avl, otherwise server environment will be hurted. We're not going to need this feature to run kde well, or to do compiles, but people using the 3.5G per-task patch or using a 64bit userspace becaue they're too strict in 3.5G are certainly going to strictly need this optimization. I certainly prefer to do the merging at the kernel layer because it's generic and it doesn't optimize only malloc users. Andrea - 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.2-ac5] X (4.0.1) crashes
Hi! > > I use XFree86 4.0.1 with nvidia-drivers 0.96. > > Take it up with nvidia. Obfuscated effectively binary only code isnt anyone > elses problem Is it legal, BTW? Obfuscated drivers should _not_ be linked into kernel, because they are not "form preferable for editing". The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source So nvidia drivers *are* binary only, as far as GPL is concerned. They should never be linked into kernel. [Or, someone should get kernel with nvidia drivers compiled in from nvidia, and then ask them for sources :-)] Pavel -- I'm [EMAIL PROTECTED] "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch][rfc][rft] vm throughput 2.4.2-ac4
On Thu, 1 Mar 2001, Rik van Riel wrote: > On Thu, 1 Mar 2001, Mike Galbraith wrote: > > On Wed, 28 Feb 2001, Rik van Riel wrote: > > > On Wed, 28 Feb 2001, Marcelo Tosatti wrote: > > > > On Wed, 28 Feb 2001, Mike Galbraith wrote: > > > > > > > > That's one reason I tossed it out. I don't _think_ it should have any > > > > > negative effect on other loads, but a test run might find otherwise. > > > > > > > > Writes are more expensive than reads. Apart from the aggressive read > > > > caching on the disk, writes have limited caching or no caching at all if > > > > you need security (journalling, for example). (I'm not sure about write > > > > caching details, any harddisk expert?) > > > > > > I suspect Mike needs to change his benchmark load a little > > > so that it dirties only 10% of the pages (might be realistic > > > for web and/or database loads). > > > > Asking the user to not dirty so many pages is wrong. My benchmark > > load is many compute intensive tasks which each dirty a few pages > > while doing real work. It would be unrealistic if it just dirtied > > pages as fast as possible to intentionally jam up the vm, but it > > doesn't do that. > > Asking you to test a different kind of workload is wrong ?? No no no and again no (perhaps I misread that bit). But otoh, you haven't tested the patch I sent in good faith. I sent it because I have thought about it. I may be wrong in my interpretation of the results, but those results were thought about.. and they exist. > The kind of load I described _is_ realistic, think for example > about ftp/www/MySQL servers... Yes. My favorite test load is also realistic. > > > At that point, you should be able to see that doing writes > > > all the time can really mess up read performance due to extra > > > introduced seeks. > > > > The fact that writes are painful doesn't change the fact that data > > must be written in order to free memory and proceed. Besides, the > > elevator is supposed to solve that not the allocator.. or? > > But if the amount of dirtied pages is _small_, it means that we can > allow the reads to continue uninterrupted for a while before we > flush all dirty pages in one go... "If wishes were horses, beggers would ride." There is no mechanysm in place that ensures that dirty pages can't get out of control, and they do in fact get out of control, and it is exaserbated (mho) by attempting to define 'too much I/O' without any information to base this definition upon. > Also, the elevator can only try to optimise whatever you throw at > it. If you throw random requests at the elevator, you cannot expect > it to do ANY GOOD ... This is a very good point (which I will think upon). I ask you this in return. Why do you think that the random junk you throw at the elevator is different than the random junk I throw at it? ;-) I see no difference at all.. it's the same exact junk. (it's junk because neither of us knows that it will be optimizable.. it really is a random bunch of pages because we have ZERO information concerning the origins, destinations nor informational content of the pages we're pushing. We have no interest [only because we aren't clever enough to be interested] in these things.) > The merging at the elevator level only works if the requests sent to > it are right next to each other on disk. This means that randomly > sending stuff to disk really DOES DESTROY PERFORMANCE and there's > nothing the elevator could ever hope to do about that. True to some (very real) extent because of the limited buffering of requests. However, I can not find any useful information that the vm is using to guarantee the IT does not destroy performance by your own definition. If it's there and I'm just missing it, I'd thank you heartily if you'd hit me up side the head with a clue-x-4 ;-) > > > We probably want some in-between solution (like FreeBSD has today). > > > The first time they see a dirty page, they mark it as seen, the > > > second time they come across it in the inactive list, they flush it. > > > This way IO is still delayed a bit and not done if there are enough > > > clean pages around. > > > > (delayed write is fine, but I'll be upset if vmlinux doesn't show up > > after I buy more ram;) > > Writing out of old data is a task independent of the VM. This is a > job done by kupdate. The only thing the VM does is write pages out > earlier when it's under memory pressure. I was joking. > > > Another solution would be to do some more explicit IO clustering and > > > only flush _large_ clusters ... no need to invoke extra disk seeks > > > just to free a single page, unless you only have single pages left. > > > > This sounds good.. except I keep thinking about the elevator. > > Clusters disappear as soon as they hit the queues so clustering > > at the vm level doesn't make any sense to me. > > You should think about the elevator a bit more. Feel for the poor > thing and try to send it requests it can actually do somethi
Re: Hashing and directories
Hi! > I was hoping to point out that in real life, most systems that > need to access large numbers of files are already designed to do > some kind of hashing, or at least to divide-and-conquer by using > multi-level directory structures. Yes -- because their workaround kernel slowness. I had to do this kind of hashing because kernel disliked 7 html files (copy of train time tables). BTW try rm * with 7 files in directory -- command line will overflow. > A particular reason for this, apart from filesystem efficiency, > is to make it easier for people to find things, as it is usually > easier to spot what you want amongst a hundred things than among > a thousand or ten thousand. Yes? Easier to type cat timetab1/2345 that can timetab12345? With bigger command line size, putting i into *one& directory is definitely easier. > A couple of practical examples from work here at Netcom UK (now > Ebone :), would be say DNS zone files or user authentication data. > We use Solaris and NFS a lot, too, so large directories are a bad > thing in general for us, so we tend to subdivide things using a > very simple scheme: taking the first letter and then sometimes > the second letter or a pair of letters from the filename. This > actually works extremely well in practice, and as mentioned above > provides some positive side-effects. Positive? Try listing all names that contain "linux" with such case. I'll do ls *linux*. You'll need ls */*linux* ?l/inux* li/nux*. Seems ugly to me. Pavel -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New net features for added performance
Hi! > > an alloc of a PKT_BUF_SZ'd skb immediately follows a free of a > > same-sized skb. 100% of the time. > > Free/Alloc gives the mm the chance to throttle it by failing, and also to > recover from fragmentation by packing the slabs. If you don't do it you need > to add a hook somewhere that gets triggered on low memory situations and > frees the buffers. And what? It makes allocation longer lived. Our MM should survive that just fine. -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Wrong data [was Re: Incorrect module init message..]
Hi! > >There's nothing wrong with the mailing list. Pavel, please set your clock > >correctly :-) > > No, Pavel's clock is fine AFAIK. The message was sent in > January. However, it was just received AGAIN today. I don't Unfortunately, my clock is b0rken. This damn little machine just does not have ability to retain time across reboot. [For booting, I need winCE. WinCE will crash upon boot if something unexpected (like linux) is in memory. Therefore I need to remove main battery for reboot :-(.] It even does not have ability to retain time correctly during powersave mode, but that could be solved. Before someone says "NTP", this machine is usually not connected anywhere -- it comunicates via ATA flash. Maybe I could scan flash for newest timestamp and use that for date... Oh, and it might be possible that mail was accidentaly sent twice. Sorry for confusion. > Press every key to continue. :-) -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, no usable clock. details at http://atreycuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.1 network (socket) performance
Hi!
> Hello, I am trying to find the reason for very, very poor network
> performance with sustained data transfers on Linux 2.4.1. I found
> a work-around, but don't think user-mode code should have to provide
> such work-arounds.
>
>In the following, with Linux 2.4.1, on a dedicated 100/Base
>link:
>
> s = socket connected to DISCARD (null-sink) server.
>
> while(len)
> {
> stat = write(s, buf, min(len, MTU));
> /* Yes, I do check for an error */
> buf += stat;
> len -= stat;
> }
>
> Data length is 0x0001 bytes.
>
> MTU Average trans rate Fastest trans rate
> --
> 655360.468 Mb/s 0.902 Mb/s
> 327680.684 Mb/s 0.813 Mb/s
> 163842.989 Mb/s 3.121 Mb/s
> 8192 5.211 Mb/s 6.160 Mb/s
> 4094 8.212 Mb/s 9.101 Mb/s
> 2048 8.561 Mb/s 9.280 Mb/s
> 1024 7.250 Mb/s 7.500 Mb/s
> 512 4.818 Mb/s 5.107 Mb/s
>
> As you can see, there is a maximum data length that can be
> handled with reasonable speed from a socket. Trying to find
> out what that was, I discovered that the best MTU was 3924.
> I don't know why. It shows:
Looks like that's page_size - epsilon.
> MTU Average trans rate Fastest trans rate
> --
> 3924 8.920 Mb/s 9.31 Mb/s
But even this is *not* reasonable speed for 100MBit ethernet!
> If the user's data length is higher than this, there is a 1/100th
> of a second wait between packets. The larger the user's data length,
> the more the data gets chopped up into 1/100th of a second intervals.
>
> It looks as though user data that can't fit into two Ethernet packets
> is queued until the next time-slice on a 100 Hz system. This severely
> hurts sustained data performance. The performance with a single
> 64k data buffer is abysmal. If it gets chopped up into 2048 byte
> blocks in user-space, it's reasonable.
>
> Both machines are Dual Pentium 600 MHz machines with identical eepro100
> Ethernet boards. I substituted, LANCE (Hewlett Packard), and 3COM boards
> (3c59x) with essentially no change.
Strange. Do you have interrupts working okay? [I'm able to get 4Mbit with
ne2000 hooked on timer IRQ, so this is not totally stupid Question.]
> Does this point out a problem? Or should user-mode code be required
Definitely problem.
> to chop up data lengths to something more "reasonable" for the kernel?
> If so, how does the user know what "reasonable" is?
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] new setprocuid syscall
Hi! > The conclusion: it's cannot be implemented without slowdown. > So ignore my patch. Of course it can. One possibility would be to implement it as ptrace(SETUID) and only allow it if we know other task is not in kernel. [And then cean up any remaining problems.] -- Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disk change messages
Hi!
> I've been trying to use vold to automount CDs. The daemon tries to open
> /dev/cdrom and if it succeeds it examines the media and mounts it under
> /cdrom/volume_name.
>
> The problem is that when there is no disk in the drive the following
> message:
> VFS: Disk change detected on device ide1(22,0)
> is written to system log during each open call. Vold calls open every 5
> seconds, so it's 17280 lines in log/day. I have been able to avoid these
> messages by commenting out a line in drivers/ide/ide-cd.c (patch
> included) and have not seen any problems yet.
>
> I guess I have three questions:
> 1. can this patch break things ? I suppose it could happen only
No.
> 2. is it possible to avoid the message by modifying vold ? E.g. finding
> out that there is no media in the drive without calling open.
Don't think so.
> 3. is there a clean way to avoid these repeated messages ?
Syslogdshould sumarize "last message repeated 123456 times"
.
> Thanks, Petr
>
> --- ide-cd.c2001/02/22 22:30:02 1.1.1.11
> +++ ide-cd.c2001/02/27 19:51:58
> @@ -601,7 +601,7 @@
>
> /* Check for tray open. */
> if (sense_key == NOT_READY) {
> - cdrom_saw_media_change (drive);
> +/* cdrom_saw_media_change (drive); */
> } else if (sense_key == UNIT_ATTENTION) {
> /* Check for media change. */
> cdrom_saw_media_change (drive);
>
> -
> 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/
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: The IO problem on multiple PCI busses
Benjamin Herrenschmidt writes:
> Also, an ioctl to retreive the iobase would be useful too
No, the whole point of my suggested mmap() interface is to
_ENTIRELY_ eliminate any reason for the user to even see
what the physical addressing of the machine looks like.
If you start pushing iobases to the user, you break this.
I do not want an interface where the user still has to do
grotty stuff like mmap() on /dev/{mem,kmem}, this was the
core of the problem I had with the syscall idea, don't bring
it back.
Make mmap()'s on a PCI-->ISA bridge do something special, for
example.
The user doesn't need to know anything about physical addressing of
the machine, it all can and should be abstracted away. This is why I
really detest the XFree86 PCI bus probing layer, it should not need to
poke around at so much of the config space information of devices :-(
It is the reason why, at least still today in Xfree86 CVS, it simply
cannot cope with multiple PCI controllers in a machine because it
assumes a flat MEM/IO space. They know about the problem and are
working on fixes, but my point is that making this overly knowledgable
PCI prober in the first place is what created these problems.
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: The IO problem on multiple PCI busses
Dan Malek writes: > It actually caused me to think of something elseI have cards > with multiple memory and I/O spaces (rare, but I have them). So what? All such bar's within mem/io space are part of unique regions of the total MEM/IO space. Thus you can pass non-conflicting offset/size pairs, based upon the BAR value of interest, to mmap and everything is fine. 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: What is 2.4 Linux networking performance like compared to BSD?
Hello! > They know that iMimic's polymix performance on Linux 2.2.* is half what it is on > BSD. What is "iMimic's polymix"? I am almost sure, it is simply buggy and was not _debugged_ under linux. Alexey - 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: [CFT][PATCH] Re: fat problem in 2.4.2
On Thu, 1 Mar 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Alexander Viro <[EMAIL PROTECTED]> wrote: > > > >Alan, fix is really quite simple. Especially if you have vmtruncate() > >returning int (ac1 used to do it, I didn't check later ones). Actually > >just a generic_cont_expand() done on expanding path in vmtruncate() > >will be enough - it should be OK for all cases, including normal > >filesystems. > > > >OK, any brave soul to test that? All I can promise that it builds. > > This looks like it would create a dummy block even for non-broken > filesystems (ie truncating a file to be larger on ext2 would create a > block, no?). While that would work, it would also waste disk-space. yeah... Frankly, I'd just do --- buffer.cThu Mar 1 15:16:34 2001 +++ buffer.c.oldThu Mar 1 15:17:55 2001 @@ -1571,6 +1571,9 @@ struct buffer_head *bh, *head, *wait[2], **wait_bh=wait; char *kaddr = kmap(page); + if (from >= to) + goto done; + blocksize = inode->i_sb->s_blocksize; if (!page->buffers) create_empty_buffers(page, inode->i_dev, blocksize); @@ -1626,6 +1629,7 @@ if (!buffer_uptodate(*wait_bh)) goto out; } +done: return 0; out: bh = head; @@ -1648,6 +1652,9 @@ unsigned blocksize; struct buffer_head *bh, *head; + if (from >= to) + goto done; + blocksize = inode->i_sb->s_blocksize; for(bh = head = page->buffers, block_start = 0; @@ -1677,6 +1684,7 @@ */ if (!partial) SetPageUptodate(page); +done: return 0; } - obviously correct, avoids disk waste and since we do it in __block... everything keeps working (block_... versions are obviously OK, cont_... also does the right thing). Dunno. I like the idea of expanding truncate() being the same as lseek() + empty write(). After all, that's what it is. Comments? Cheers, Al - 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 IO problem on multiple PCI busses
Benjamin Herrenschmidt writes: > Also, the problem of finding where the legacy ISA IOs of a given PCI bus > are is a bit different that simply mmap'ing a BAR. Some video cards > require some access to their VGA IOs without having a BAR covering them, > in some case it's necessary to switch the chip from VGA to MMIO mode. Many platforms, sparc64 included, do not have an ISA IO space nor do they provide VGA accesses at all. If things such as XFree86 are coded for such platforms to not require VGA accesses (the 'ati' driver is already like this when certain build time defines are set), this could become a non-issue in this case. > So what would be a preferred way ? Create that fake ISA bus number and > provide functions for looking them up, getting their IO and mem bases, > and eventually mapping PCI busses to ISA busses ? Or does someone have a > better idea ? The goal is to try not to change the semantics of inb/outb > and friends so that most legacy drivers can still work using the > "default" IO bus if they are not upgraded to the new scheme. There is no 'fake' ISA bus number you need. There is a 'real' one, the one on which the PCI-->ISA bridge lives, why not use that one :-) Then you could find such an ISA bridge, open that PCI device, then finally perform the PCI_IOCTL_GETIOBASE thingy on it, but I don't like this get-iobase idea at all, see my next email in this thread for why. 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: Q: explicit alignment control for the slab allocator
On Thu, 1 Mar 2001, Manfred Spraul wrote: > Mark Hemment wrote: > > > > The original idea behind offset was for objects with a "hot" area > > greater than a single L1 cache line. By using offset correctly (and to my > > knowledge it has never been used anywhere in the Linux kernel), a SLAB > > cache creator (caller of kmem_cache_create()) could ask the SLAB for more > > than one colour (space/L1 cache lines) offset between objects. > > > > What's the difference between this definition of 'offset' and alignment? The positioning of the first object within a slab (at least that is how it is suppose to work). The distance between all objects within a slab is constant, so the colouring of objects depends upon the cache line (offset) the first object is placed on. The alignment is the boundary objects fall upon within a slab. This may require 'padding' between the objects so they fall on the correct boundaries (ie. they aren't a 'natural' size). For kmem_cache_create(), a zero offset means the offset is the same as the alignment. Take the case of offset being 64, and alignment being 32. Here, the allocator attempts to place the first object on a 64byte boundary (say, at offset 0), and all subsequent objects (within the same cache) on a 32byte boundary. Now, when it comes to construct the next slab, it tries to place the first object 64bytes offset from the first object in the previous slab (say, at offset 64). The distance between the objects is still the same - ie. they fall on 32byte boundaries. See the difference? > alignment means that (addr%alignment==0) > offset means that (addr1-addr2 == n*offset) > > Isn't the only difference the alignment of the first object in a slab? Yes (as explained above). It is important. > Some hardware drivers use HW_CACHEALIGN and assume certain byte > alignments, and arm needs 1024 byte aligned blocks. I should have put a big comment in the allocator, saying aligment/offset are only hints to the allocator and not guarantees. Unfortunately, the allocator was always returning L1 aligned objects with HW_CACHEALIGN, so folks started to depend on it. Too late to break that now. It sounds as if HW_CACHEALIGN has been broken by a config option, and this needs to be fixed. But leave 'offset' alone?! If it isn't working as described above, then it needs fixing, but don't change its definition. 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/
