Re: Abysmal RECV network performance
> Can someone please help me troubleshoot this problem - > I am getting abysmal (see numbers below) network performance > on my system, but the poor performance seems limited to receiving > data. Transmission is OK. [ snip ] > What kind of performance should I be seeing with a P-90 > on a 100Mbps connection? I was expecting something in the > range of 40-70 Mbps - certainly not 1-2 Mbps. > > What can I do to track this problem down? Has anyone else > had problems like this? While we didnt use 2.2 kernels at all, we did similar tests on 2.4.0 through 2.4.4 kernels, on UP and SMP. I've used a similar machine (PII 333MHz) as well as faster (866MHz) machines, and got pretty nifty (> 90Mbs) throughput on netperf tests (tcp stream, no disk I/O) over a 100Mb full duplex link. (not sure if there are any P-90 issues). Throughput does drop with small MTU, very small packet sizes, small socket buffer sizes, but only at extremes, for the most part throughput was well over 70Mbs. (this is true for single connections, you dont mention how many connections you were scaling to, if any). However, we did run into serious performance problems with the Netgear FA311/2 (tulip). Found that the link lost connectivity because of card lockups and transmit timeout failures - and some of these were silent. However, I moved to the 3C905C (3c59x driver) which behaved like a champ, and we didnt see the problems any more, so have stuck to that card. This was back in the 2.4.0 time frame, and there have many patches since then to various drivers, so not sure if the problem(s) have been resolved or not (likely to have been, extensively reported). Both your cards might actually be underperforming.. Are you seeing any errors reported in /var/log/messages? Are you monitoring your connection via tcpdump, for example? You might sometimes see long gaps in transmission...Are there any abnormal numbers in /proc/net/ stats? I dont remember seeing that high frame errors, although there were a few. HW checksumming for the kind of test you are doing (tcp, mostly fast path) will not buy you any real performance gain, the checksum is actually consumed by the user-kernel copy routine. You can also run the tests on a profiling kernel and compare results... Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technology Center [EMAIL PROTECTED] IBM Beaverton, OR [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: BUG REPORT: 2.4.4 hang on large network transfers with RTL-8139
Anton Voloshin wrote: > Hello, > > I've got a kernel hang (can easily be reproduced on my computer). > It happens on relatively large outgoing network traffic. > For instance, on trying to upload some large file from workstation to > other machine via SMB or FTP. > > On 2.4.4 hang was after sending about 20Kb. > On 2.4.5 it seems to hang after 870+ Kb. > When sending data via slow link (e.g. local Ethernet -> remote modem), > everything is Ok. > > Network card is (taken from /proc/pci): > > Bus 1, device 11, function 0: > Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). > IRQ 10. > Master Capable. Latency=208. Min Gnt=32.Max Lat=64. > I/O at 0x7800 [0x78ff]. > Non-prefetchable 32 bit memory at 0xfebfff00 [0xfebf]. > > 2.4.3 works Ok, 2.4.4 and 2.4.5 both has this problem. > > Lamer's assumption: maybe troubles with sendfile() after zero-copy patches? > Actually I get the same problem (I kind of have to run 2.4.5-ac2 however). I just try not to download or upload large files over fast links. Glenn Shannon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Part II of Lameness...
athy:/src/DiskPerf-1.0.4 # ./DiskPerf /dev/hda Device: IBM-DTLA-307075 Serial Number: YSDYSFA5874 LBA 0 DMA Read Test = 45.73 MB/Sec (5.47 Seconds) Outer Diameter Sequential DMA Read Test = 35.85 MB/Sec (6.97 Seconds) Inner Diameter Sequential DMA Read Test = 17.62 MB/Sec (14.19 Seconds) Sorry I do not have the other boxes configured with a kernel to accept this test callout. However I do have systems that rip at 63 MB/Sec and if you adjust for CR3's between kernel to user-space it comes out to about 93 MB/Sec. There is nothing LAME or LACKING about that performance! 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/
BUG REPORT: 2.4.4 hang on large network transfers with RTL-8139
Hello, I've got a kernel hang (can easily be reproduced on my computer). It happens on relatively large outgoing network traffic. For instance, on trying to upload some large file from workstation to other machine via SMB or FTP. On 2.4.4 hang was after sending about 20Kb. On 2.4.5 it seems to hang after 870+ Kb. When sending data via slow link (e.g. local Ethernet -> remote modem), everything is Ok. Network card is (taken from /proc/pci): Bus 1, device 11, function 0: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 16). IRQ 10. Master Capable. Latency=208. Min Gnt=32.Max Lat=64. I/O at 0x7800 [0x78ff]. Non-prefetchable 32 bit memory at 0xfebfff00 [0xfebf]. 2.4.3 works Ok, 2.4.4 and 2.4.5 both has this problem. Lamer's assumption: maybe troubles with sendfile() after zero-copy patches? -- Anton <[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/
[PATCH] panic in scsi_free/sr_scatter_pad
I think I recall seeing something reported like this on the list(?):
sr: ran out of mem for scatter pad
Kernel panic: scsi_free: bad offset
Regardless, I've seen this on 2.4.5, aha1542, 40MB, mount /dev/scd0 after
a fresh reboot and spark, pop, fizz, plop...
Seems there is a bug in sr_scatter_pad() associated with ENOMEM handling.
AFAICT it goes something like this:
- sr_scatter_pad increases use_sg (and sglist_len)
- scsi_malloc(sglist_len) returns NULL (hence message 1)
- sr_scatter_pad bails out but leaves increased values
- scsi_release_buffers loops on use_sg, calls scsi_free each time.
- scsi_free gets called with random garbage - hence message 2. 8-)
Restoring the old info back into SCpnt fixes the panic - patch
follows. I'll have to read some more to determine why scsi_malloc is
having trouble in handing out ISA DMA mem and causing the 1st message...
Paul.
--- drivers/scsi/sr.c~ Sun May 27 03:53:26 2001
+++ drivers/scsi/sr.c Tue May 29 01:46:29 2001
@@ -31,6 +31,8 @@
* Modified by Arnaldo Carvalho de Melo <[EMAIL PROTECTED]>
* check resource allocation in sr_init and some cleanups
*
+ * Restore SCpnt state if scsi_malloc fails in sr_scatter_pad - Paul G.
+ *
*/
#include
@@ -263,10 +265,13 @@
{
struct scatterlist *sg, *old_sg = NULL;
int i, fsize, bsize, sg_ent;
+ unsigned short old_sglist_len;
char *front, *back;
back = front = NULL;
sg_ent = SCpnt->use_sg;
+ old_sglist_len = SCpnt->sglist_len;
+ SCpnt->old_use_sg = SCpnt->use_sg;
bsize = 0; /* gcc... */
/*
@@ -332,6 +337,8 @@
no_mem:
printk("sr: ran out of mem for scatter pad\n");
+ SCpnt->use_sg = SCpnt->old_use_sg;
+ SCpnt->sglist_len = old_sglist_len;
if (front)
scsi_free(front, fsize);
if (back)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Plain 2.4.5 VM...
On Tue, 29 May 2001, Jeff Garzik wrote: > > On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote: > > > > > > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K > > > > > buff > > > > > Swap: 255608K av, 255608K used, 0K free 215744K > > > > > cached > > > > > > > > > > Vanilla 2.4.5 VM. > > > > > It's not a bug. It's a feature. It only breaks systems that are run with > > > "too little" swap, and the only difference from 2.2 till now is, that the > > > definition of "too little" changed. > > I am surprised as many people as this are missing, > > * when you have an active process using ~300M of VM, in a ~380M machine, > 2/3 of the machine's RAM should -not- be soaked up by cache Emphatic yes. We went from cache collapse to cache bloat. IMHO, the bugfix for collapse exposed other problems. I posted a patch which I believe demonstrated that pretty well. (i also bet Rik a virtual beer that folks would knock on his mailbox when 2.4.5 was released. please cc him somebody.. i want my brewski;) -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: Plain 2.4.5 VM...
> On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote: > > > > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K > > > > buff > > > > Swap: 255608K av, 255608K used, 0K free 215744K > > > > cached > > > > > > > > Vanilla 2.4.5 VM. > > > It's not a bug. It's a feature. It only breaks systems that are run with > > "too little" swap, and the only difference from 2.2 till now is, that the > > definition of "too little" changed. I am surprised as many people as this are missing, * when you have an active process using ~300M of VM, in a ~380M machine, 2/3 of the machine's RAM should -not- be soaked up by cache * when you have an active process using ~300M of VM, in a ~380M machine, swap should not be full while there is 133M of RAM available. The above quoted is top output, taken during the several minutes where cc1plus process was ~300M in size. Similar numbers existed before and after my cut-n-paste, so this was not transient behavior. I can assure you, these are bugs not features :) -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
via-rhine
Regarding previous posts i've made on this subject, it turns out that using a card with this chipset (i assume all cards - i've only tried a DFE-530TX) will only reset on a cold boot, and are upset when booted to windows (it causes them to not respond in linux) A cold boot fixes the problem. I'm not sure if this chipset is able to be reset "on the fly" but I sure am interested.. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH - ksymoops on Alpha - 2.4.5-ac3
> George France <[EMAIL PROTECTED]> wrote:
> >Here is a trivial patch that will make ksymoops work again on Alpha.
Cleaner patch.
diff -urN linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c
linux-2.4.5/arch/alpha/kernel/traps.c
--- linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c Thu May 24 17:24:37 2001
+++ linux-2.4.5/arch/alpha/kernel/traps.c Tue May 29 00:42:40 2001
@@ -286,17 +286,11 @@
continue;
if (tmp >= (unsigned long) &_etext)
continue;
- /*
-* Assume that only the low 24-bits of a kernel text address
-* is interesting.
-*/
- printk("%6x%c", (int)tmp & 0xff, (++i % 11) ? ' ' : '\n');
-#if 0
+ printk("%lx%c", tmp, ' ');
if (i > 40) {
printk(" ...");
break;
}
-#endif
}
printk("\n");
}
>
> Thanks for that. Now if you can just persuade the Alpha people to
> print the 'Code:' line in the same format as other architectures then
> ksymoops can decode the instructions as well. If Alpha wants to
> include its own instruction decoder as well then that is up to them but
> I would appreciate a standard 'Code:' line being printed first.
Could you send me an oops with the standard 'Code:' line?
Best Regards,
--George
diff -urN linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c linux-2.4.5/arch/alpha/kernel/traps.c
--- linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c Thu May 24 17:24:37 2001
+++ linux-2.4.5/arch/alpha/kernel/traps.c Tue May 29 00:42:40 2001
@@ -286,17 +286,11 @@
continue;
if (tmp >= (unsigned long) &_etext)
continue;
- /*
- * Assume that only the low 24-bits of a kernel text address
- * is interesting.
- */
- printk("%6x%c", (int)tmp & 0xff, (++i % 11) ? ' ' : '\n');
-#if 0
+ printk("%lx%c", tmp, ' ');
if (i > 40) {
printk(" ...");
break;
}
-#endif
}
printk("\n");
}
Re: Linux 2.4.5-ac2
On Mon, 28 May 2001, Marcelo Tosatti wrote: > On Mon, 28 May 2001, Mike Galbraith wrote: > > > On Mon, 28 May 2001, Leeuw van der, Tim wrote: > > > > > The VM in 2.4.5 might be largely 'fixed' and I know that the VM changes in > > > -ac were considered to be but still broken, however for me they worked > > > better than what is in 2.4.5. > > > > The VM changes in 2.4.5 fixed a very serious performance problem. IMHO, > > 2.4.5 is a step in the right direction. (and I hope more steps are in > > the offing;) > > It did not fixed any interactivity problem. Yes, I know. I mentioned that interactivity went south here back when we stopped waiting. The performance problem I was refering to was the cache collapsing as soon as you hit a load spike. You and Rik killed that longstanding problem. -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: Plain 2.4.5 VM...
On Tue, May 29, 2001 at 01:46:28PM +0900, G. Hugh Song wrote:
> Jakob,
>
> My Alpha has 2GB of physical memory. In this case how much swap space
> should
> I assign in these days of kernel 2.4.*? I had had trouble with 1GB of
> swap space
> before switching back to 2.2.20pre2aa1.
If you run a single mingetty and bash session, you need no swap.
If you run four 1GB processes concurrently, I would use ~5-6G of swap to be on
the safe side.
Swap is very cheap, even if measured in gigabytes. Go with the sum of the
largest process foot-prints you can imagine running on your system, and then
add some. Be generous. It's not like unused swap space is going to slow the
system down - it's a nice extra little safety to have. It's beyond me why
anyone would run a system with marginal swap.
On a compile box here with 392 MB physical, I have 900 MB swap. This
accomodates multiple concurrent 100-300 MB compile jobs. Never had a problem.
Oh, and I didn't have to change my swap setup between 2.2 and 2.4.
--
: [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}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AT keyboard optional on i386?
Hi, James! > So as you can see even USB keyboards depend on pc_keyb.c. So their is > no way around this. Perhaps redefining kbd_read_input() will help. It's cruel, I know :-) > You can a few nice tricks with it like plug in two PS/2 keyboards. I > have this for my home setup. The only thing is make sure you don't > have both keyboards plugged in when you turn your PC on. I found BIOS > get confused by two PS/2 keyboards. As you can it is very easy to > multiplex many keyboards with the above design. I have had 4 different > keyboards hooked up to my system and functioning at the same time. We > even got a Sun keyboard to work on a intel box :-) That's what we like Linux for. It doesn't get confused when everything else does :-) Thanks for your very interesting reply. -- Regards, Pavel Roskin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Plain 2.4.5 VM...
Jakob, My Alpha has 2GB of physical memory. In this case how much swap space should I assign in these days of kernel 2.4.*? I had had trouble with 1GB of swap space before switching back to 2.2.20pre2aa1. Thanks -- G. Hugh Song - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: (via-rhine.c problem) 2.4.5 and pppd/pppoe
Ok, I have decided the problem lays in via-rhine.c, the ethernet driver for my card. The second boot finds the mac address as 00's all the time, regardless of whether the driver is compiled as a module, or monolith. On 28 May 2001 16:18:55 -0400, Daniel Rose wrote: > > Hello, > I'm having problems with 2.4.5 and my pppoe connection. > The kernel compiles fine, and works fine too, until I reboot, at which > time it decides it no longer wants to work, and any time I attempt to > call my start-pppoe script, i get: > > May 28 15:54:28 rocket pppd[3091]: pppd 2.4.1 started by root, uid 0 > May 28 15:54:28 rocket pppd[3091]: Using interface ppp0 > May 28 15:54:28 rocket pppd[3091]: Connect: ppp0 <--> /dev/ttyp0 > May 28 15:54:43 rocket pppd[3091]: Hangup (SIGHUP) > May 28 15:54:43 rocket pppd[3091]: Modem hangup > May 28 15:54:43 rocket pppd[3091]: Connection terminated. > May 28 15:54:44 rocket pppd[3091]: Exit. > > I am assuming that this is because of my eth0, which shows in ifconfig: > > eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 (it's using > via-rhine chipset, compiled into kernel, not a module) > > This _only_ occurs after I reboot (ie. i can start up the new 2.4.5 > kernel and work it perfectly once, then reboot and it doesnt work) > > Anybody have any ideas? > > Thanks, > > Daniel Rose > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM...
On Tuesday 29 May 2001 00:10, Jakob Østergaard wrote: > > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K > > > buff > > > Swap: 255608K av, 255608K used, 0K free 215744K > > > cached > > > > > > Vanilla 2.4.5 VM. > It's not a bug. It's a feature. It only breaks systems that are run with > "too little" swap, and the only difference from 2.2 till now is, that the > definition of "too little" changed. Sorry but if ~250MB is too little ... it _is_ a bug. I think everyone would agree that 250MB of swap in use is far far far too much. If this is a feature, it is one nobody would want. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Serial Programming
Hi,
I am developing a driver which reads some data from the serial port in the
raw mode. For doing the same i do a call to which fails. The call to
our_ioctl for get serial data fails with return value -14 which is EBADADDR.
The same read works if we send a direct read request from an application to
our driver. However when we call the same thing from within the driver
module, it fails .
Please suggest a way for this.
The code is something like this
FILE * fp;
init_module()
{
fp = filp_open ("/dev/ttyS0", O_RDWR);
}
int our_read(struct file *filp, char *buf, size_t size, loff_t *off)
{
if (fp)
{
if (fp->f_op && fp->f_op->read)
retval = fp->f_op->read(filep,buf,size,&filep->f_pos);
}
}
int our_ioctl(struct inode *in, struct file *f, unsigned int cmd,
unsigned long arg)
{
switch (cmd)
{
case GET_SERIAL_DATA : return our_read(NULL, (char * ) arg,
MAX_READ, NULL);
break;
}
}
TIA
Harivansh S. Mehta
DCM Technologies Ltd.
India
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AT keyboard optional on i386?
> I'm trying to run Linux on a broken motherboard that is constantly > producing random noice on the AT keyboard port. I'm going to use a USB > keyboard, but I cannot get Linux to ignore the AT keyboard port. Not that I know. The current way it works is: 1) Current 2.4 way for AT keyboards: pc_keyb.c -(raw)-> keyboard.c -(raw)-> pc_keyb.c --> >--(cooked)-> keyboard.c -(chars)-> tty 2) Current 2.4 way for USB keyboards (uses keybdev): usb.c -(usb)-> hid.c -(events)-> input.c -(events)-> keybdev.c --> >--(raw)-> keyboard.c -(raw)-> pc_keyb.c -(cooked)-> keyboard.c --> >--(chars)-> tty So as you can see even USB keyboards depend on pc_keyb.c. So their is no way around this. > Is there any way to disable the AT keyboard? I think the best solution > would be to make it optional, just like almost everything in the kernel, > e.g. PS/2 mouse. Some embedded i386 systems could save a few kilobytes of > RAM by disabling the AT keyboard. This is a 2.5.X issue since changing the current pc_keyb.c keyboard driver would break many drivers which like the USB keybaords fake they are PS/2 keyboards. BTW I already have a kernel tree that does allow the AT keyboard to be optional. The AT keyboard has been ported to the linux input api and it has been working very well for along time. In this kernel tree you have: 3) Ruby (my tree's name) way for AT keyboards: i8042.c -(raw)-> atkbd.c -(events)-> input.c --> >--(events)-> keyboard.c -(chars)-> tty 4) Ruby way for USB keyboards: usb.c -(usb)-> hid.c -(events)-> input.c --> >--(events)-> keyboard.c -(chars)-> tty You can a few nice tricks with it like plug in two PS/2 keyboards. I have this for my home setup. The only thing is make sure you don't have both keyboards plugged in when you turn your PC on. I found BIOS get confussed by two PS/2 keyboards. As you can it is very easy to multiplex many keyboards with the above design. I have had 4 different keyboards hooked up to my system and functioning at the same time. We even got a Sun keyboard to work on a intel box :-) Another nice feature is event numbers from the input api can be used in the keymap. This has a nice effect that keymaps will be architecture independent, too. The only mess is raw mode which /dev/event makes obsolute. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Plain 2.4.5 VM...
On Tue, May 29, 2001 at 11:32:09AM +0900, G. Hugh Song wrote:
>
> Jeff Garzik wrote:
> >
> > Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M
> > cc1plus process size. Unfortunately this leads the machine with 380M of
> > RAM deeply into swap:
> >
> > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K
> > buff
> > Swap: 255608K av, 255608K used, 0K free 215744K
> > cached
> >
> > Vanilla 2.4.5 VM.
> >
>
> This bug known as the swap-reclaim bug has been there for a while since
> around 2.4.4. Rick van Riel said that it is in the TO-DO list.
> Because of this, I went back to 2.2.20pre2aa1 on UP2000 SMP.
>
> IMHO, the current 2.4.* kernels should still be 2.3.*. When this bug
> is removed, I will come back to 2.4.*.
Just keep enough swap around. How hard can that be ?
Really, it's not like a memory leak or something. It's just "late reclaim".
If Linux didn't do over-commit, you wouldn't have been able to run that job
anyway.
It's not a bug. It's a feature. It only breaks systems that are run with "too
little" swap, and the only difference from 2.2 till now is, that the definition
of "too little" changed.
--
: [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}...:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4 kernel freeze for unknown reason
Hi all, On Fri May 11 2001 - 13:45:24 EST, Vincent Stemen ([EMAIL PROTECTED]) wrote: >On Wednesday 09 May 2001 22:57, Jacky Liu wrote: >> The machine has been randomly lockup (totally freeze) for number of >> times without any traceable clue or error message. Usually the time >> frame between each lockup is between 24 to 72 hours. The screen just >> freeze when it's lockup (either in Console or X) and no "kernel >panic" >> type or any error message prompt up. All services (SSH, DNS, etc..) >> are dead when it's lockup (...) >I have been experiencing these same problems since version 2.4.0. >Although, I think it has improved a little in 2.4.4, it still locks >up. The problem seems to be related to memory management and/or swap, >and is seems to do it primarily on machines with over 128Mb of RAM. >Although, I have not tested systematically enough to confirm this. I have the same problem on a Toshiba satellite 4070, 366 celeron, 64M ram, redhat 7.1 and vanilla 2.4.5. Exactly the same bug description. Totally reproducible. >I have been monitoring the memory usage constantly with the gnome >memory usage meter and noticed that as swap grows it is never freed >back up. I can kill off most of the large applications, such as >netscape, xemacs, etc, and little or no memory and swap will be freed. >Once swap is full after a few days, my machine will lock up. After a few *hours*. Then I have (as you said) to do swapoff /dev/hda4 ; swapon -a in order to free the swap. If I do this, everything is fine... till it fills up again. >(...)I am >disappointed that we are now on the forth 2.4.x kernel version and >such as serious problem that has been there since 2.4.0 still exists. >This is pretty much a show stopper for having a production machine. Totally agree. This is quite a showstopper. Do_try_to_free_pages, err... sorry, fix_bug. Regards, Vasco Figueira - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ctags as generated by make tags
Anyone have any good tips on getting tags to generate nicely? I'm having some problems with some tags for macros and such being declared in several places since ctags doesn't honour any CPP #if'ing. I've currently got my Makefile doing this, which seems to give me some sanity as the redefinitions tend to be made by drivers and such. I'm basically walking the include tree by depth without doing any sorting of tags and then doing a stable sort on the final tags file. --- Makefile.oldMon May 28 22:44:01 2001 +++ MakefileMon May 28 23:19:07 2001 @@ -334,10 +334,28 @@ # Exuberant ctags works better with -I tags: dummy - CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "-I __initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ + CTAGSF=`ctags --version | grep -i exuberant >/dev/null && echo "--sort=no -I +__initdata,__exitdata,EXPORT_SYMBOL,EXPORT_SYMBOL_NOVERS"`; \ ctags $$CTAGSF `find include/asm-$(ARCH) -name '*.h'` && \ - find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' -print | xargs ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 2 -maxdepth 2 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 3 -maxdepth 3 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 4 -maxdepth 4 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ + find include -type f -name '*.h' -mindepth 5 -maxdepth 5 \ + | grep -v include/asm- | grep -v include/config \ + | xargs -r ctags $$CTAGSF -a && \ find $(SUBDIRS) init -name '*.c' | xargs ctags $$CTAGSF -a + mv tags tags.unsorted + LC_ALL=C sort -k 1,1 -s tags.unsorted > tags + rm tags.unsorted + +# +#find include -type d \( -name "asm-*" -o -name config \) -prune -o -name '*.h' +-print | xargs ctags $$CTAGSF -a && \ +# ifdef CONFIG_MODULES ifdef CONFIG_MODVERSIONS Anyone else doing anything smarter? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ATI Rage 128
Go to http://www.svgalib.org. The developement svgalib drivers support fbdev and since their is a ati 128 driver :-) On Fri, 25 May 2001, Android wrote: > Are there any plans for including support for the ATI Rage 128 chipset into > svgalib? > The VESA setting does not work. Causes any program using svgalib to crash. > Are there any configuration settings in the kernel that may help with this? > > The kernel I am using is 2.4.4 and the card I am using is the Rage Fury (32 > MB). > The svgalib version is 1.4.2 > Framebuffer does have support for Rage 128, so I don't see why svgalib doesn't. > > Thanks! > >-- Ted > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM...
> Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M > cc1plus process size. Unfortunately this leads the machine with 380M of > RAM deeply into swap: > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K buff > Swap: 255608K av, 255608K used, 0K free 215744K cached > > Vanilla 2.4.5 VM. I noticed that too and there is no way around it. If we assume a 2.5xRAM target, you must add about 704MB. In my case I had no spare partition so I added a swapfile, as undoubtedly many 2.4 sufferers did. -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.2: tq_scheduler functions scheduling and waiting
Arthur Naseef wrote: > > All: > > I have been diagnosing kernel panics for over a week and I have > concerns with the use of tq_scheduler for which I was hoping I > could get some assistance. > > Is it considered acceptable for functions in the tq_scheduler > task list to call schedule? Is it acceptable for such functions > to wait on wait queues? What limitations exist? When a task wants to exit, it cleans up all its stuff, sets its state to TASK_ZOMBIE and then calls schedule(). The scheduler takes it off the runqueue and the task is never again executed. It's just a couple of stack pages which are waiting for someone in wait4() to release. But imagine what happens if the TASK_ZOMBIE task hits schedule() and finds a tq_scheduler task to run. And that task calls schedule(). In state TASK_ZOMBIE. Messy. At the very least, the schedule() call will never return. If the tq_scheduler task sets current->state to TASK_[UN]INTERRUPTIBLE (as it should) before calling schedule() then it has overwritten TASK_ZOMBIE and the task which is trying to exit has become magically resurrected. As far as I can tell, the "dead" task will run again, do the `fake_volatile' thing in do_exit() and try to go zombie again. It would be very interesting to change the test in schedule(): sti(); - if (tq_scheduler) + if (tq_scheduler && current->state != TASK_ZOMBIE) goto handle_tq_scheduler; It's all rather unpleasant, and tq_scheduler was killed in 2.4. I suggest you take a look at all the serial drivers in 2.4, see how I converted them to use schedule_task(). Someone kindly ported schedule_task() to 2.2.recent, so you should be able to use that in the same way. - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Current tulip driver from 2.4.5 is plain broken
J Brook wrote: > I see exactly the same (broken!) behaviour here. The last kernel > that > works for me in 2.4.4-ac6, which I'm running at the moment. All > subsequent -ac kernels and 2.4.5-pre4 and above are broken. I > reported > the bug last week. Quick system summary: RH7.1, Duron, KT133, Network > card chip "Digital 21041-AA". I get the same problem as above > (working > kernels set half-duplex, broken kernels set full-duplex). More > details > available on request, or at > http://boudicca.tux.org/hypermail/linux-kernel/2001week21/0278.html > > Thanks! > > John RH 7.1 running kernel 2.4.5-ac3, Dual Xeon 450, Supermicro S2DGE, Network card Macronix, Inc. [MXIC] MX987x5. tulip-diag.c:v2.08 5/15/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Macronix 98715 PMAC adapter at 0xe800. Macronix 98715 PMAC chip registers at 0xe800: 0x00: fff88000 1fefc000 1fefc200 e466 01a82202 e7ffebef 0x40: fffe 0fffcf08 fffe 40a1d0cc fff0 Extended registers: 80: 0f34 0f34 0f34 0f34 0f34 0f34 fc40 f840 a0: 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f c0: 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f e0: 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f 2001527f Port selection is 10mpbs-serial 100baseTx scrambler, full-duplex. Transmit started, Receive started, full-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit unit is set to store-and-forward. EEPROM 64 words, 6 address bits. A simplifed EEPROM data table was found. The EEPROM does not contain transceiver control information. No MII transceivers found! Works great, no problems at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Plain 2.4.5 VM...
Jeff Garzik wrote: > > Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M > cc1plus process size. Unfortunately this leads the machine with 380M of > RAM deeply into swap: > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K > buff > Swap: 255608K av, 255608K used, 0K free 215744K > cached > > Vanilla 2.4.5 VM. > This bug known as the swap-reclaim bug has been there for a while since around 2.4.4. Rick van Riel said that it is in the TO-DO list. Because of this, I went back to 2.2.20pre2aa1 on UP2000 SMP. IMHO, the current 2.4.* kernels should still be 2.3.*. When this bug is removed, I will come back to 2.4.*. Regards, Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Current tulip driver from 2.4.5 is plain broken
Michal Jaegermann wrote: > I mentioned that before but this should be stated clearly. As far > as I am concerned "Linux Tulip driver version 0.9.15-pre2 (May 16, > 2001)", as used in 2.4.5 - and other kernels - is totally buggered. > It comes up, and ethernet interfaces can be configured, but does > not matter how I am playing with options I cannot get a single > packet through. > > Replacing it in 2.4.5 with "Linux Tulip driver version 0.9.14d > (April 3, 2001)", which I have handy, restores sanity immediately > and a network simply works without any heroic efforts. > > My NIC is "Digital DS21143 Tulip rev 65 at 0x8800". BTW - a > version "tulip-1.1.7" from sourceforge behaves exactly like > 0.9.15-pre2. I see exactly the same (broken!) behaviour here. The last kernel that works for me in 2.4.4-ac6, which I'm running at the moment. All subsequent -ac kernels and 2.4.5-pre4 and above are broken. I reported the bug last week. Quick system summary: RH7.1, Duron, KT133, Network card chip "Digital 21041-AA". I get the same problem as above (working kernels set half-duplex, broken kernels set full-duplex). More details available on request, or at http://boudicca.tux.org/hypermail/linux-kernel/2001week21/0278.html Thanks! John [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: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
> = Alan Cox >> = [EMAIL PROTECTED]? >>> = ?? >>> AFAICS, the firmware is just a file served up to the device as needed >>> - no more a derivative work from the kernel than my homepage is a >>> derivative work of Apache. >> >> Indeed. But if you compiled your home page, linked it into Emacs to >> display on startup, and distributed the binary, the _combination_ >> "Emacs+homepage" binary would be a derived work, and you'd be required >> to offer source for both parts. >In which case GNU Emacs violates the GPL by containing a copy of COPYING which >is more restricted than the GPL. After all it displays copying on a hotkey >combination "M-x describe-copying" just displays the file /usr/share/emacs//etc/COPYING. The emacs binaries do not contain the text of GPL. By the way, if one wanted to #include the text of the GPL, then, in the specific case of the GPL, one could argue that the restrictions on modifying the GPL are part of the GPL and, therefore not further restrictions. (Even though those restrictions occur before the "preamble", they're just as binding and removing them would be a change to the GPL, so they are an existing restriction of the GPL rather than a further restriction.) That said, I have long advocated that authors use GPL-compatible copying conditions for everything, including plain text, to facilitate free software effects on platforms that comingle code and documentation, such as many web pages and some other interactive media. Adam J. Richter __ __ 4880 Stevens Creek Blvd, Suite 104 [EMAIL PROTECTED] \ / San Jose, California 95129-1034 A +1 408 261-6630 | g g d r a s i l United States of America fax +1 408 261-6631 "Free Software For The Rest Of Us." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel 2.4.5-ac2 OOPs when run pppd ?
Richard Gooch wrote: > > How about having a helper function for interrupt handlers which queues > characters to be sent to the console? kconsoled anyone? Blocking > interrupts is quite distressing, so we need to be consoled ;-) I don't think we need it, Richard. These writes to tty devices from interrupt context are coming from line disciplines - n_hdlc, ppp, r3964, etc. Now, while it may be amusing to see if you can successfully negotiate a PPP session by typing raw LCP, there really isn't, I believe, a useful reason for attaching one of these ldiscs to the console tty. Interrupt-context writes to the *console*, as opposed to the console *tty* work just fine, of course. printk. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Plain 2.4.5 VM...
Jeff Garzik wrote: > > Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M > cc1plus process size. Unfortunately this leads the machine with 380M of > RAM deeply into swap: > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K > buff > Swap: 255608K av, 255608K used, 0K free 215744K > cached > > Vanilla 2.4.5 VM. > Sorry. I just looked at your numbers again and saw you have 133 MB of real ram free. Is this during compile? -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Plain 2.4.5 VM...
Jeff Garzik wrote: > > Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M > cc1plus process size. Unfortunately this leads the machine with 380M of > RAM deeply into swap: > > Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K > buff > Swap: 255608K av, 255608K used, 0K free 215744K > cached > > Vanilla 2.4.5 VM. I don't think this is new/unusual. You can add the following to configure when compiling mysql .. --with-low-memory Try to use less memory to compile to avoid memory limitations. -- = Mohammad A. Haque http://www.haque.net/ [EMAIL PROTECTED] "Alcohol and calculus don't mix. Project Lead Don't drink and derive." --Unknown http://wm.themes.org/ [EMAIL PROTECTED] = - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Plain 2.4.5 VM...
Ouch! When compiling MySql, building sql_yacc.cc results in a ~300M cc1plus process size. Unfortunately this leads the machine with 380M of RAM deeply into swap: Mem: 381608K av, 248504K used, 133104K free, 0K shrd, 192K buff Swap: 255608K av, 255608K used, 0K free 215744K cached Vanilla 2.4.5 VM. -- Jeff Garzik | Disbelief, that's why you fail. Building 1024| MandrakeSoft | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-ntfs] Re: [Linux-NTFS-Dev] Re: ANN: NTFS new release available (1.1.15)
On Mon, May 28, 2001 at 03:49:28PM +0100, Anton Altaparmakov wrote: > At 14:08 28/05/2001, Yuri Per wrote: > >Anton Altaparmakov wrote: > > > >>Does anyone know what NTFS version the NT 3.1 / 3.51 volumes had? If I > >>know I can make sure we don't mount such beasts considering we know the > >>driver would fail on them... - I am aware of only one person stil using > >>NT 3.51 and he doesn't believe in the NTFS Linux driver any more, so I > >>guess we can just say we support NT 4.0 and above only. > > > >NT 3.51 uses exactly the same version of NTFS as NT 4.0 does. > > Ok. Thanks. > > Anyone know about 3.1? > > Anton > It's an HPFS variant. Try the HPFS driver, and it may work. The first cut of NT was with a hacked up HPFS driver from Microsoft OS/2. NTFS was designed internally by David G. and friends. Jeff > > -- >"Nothing succeeds like success." - Alexandre Dumas > -- > Anton Altaparmakov (replace at with @) > Linux NTFS Maintainer / WWW: http://sf.net/projects/linux-ntfs/ > ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/ > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Kurt Roeckx wrote: > You should never "return" from userspace to kernelspace. The > only way to go from user space to kernel space should be by using > a system call. That does actually happen on x86. The kernel puts a small code fragment called the "trampoline" on the user mode stack, which is run when the signal handler returns if it does a normal return. The trampoline does the system call "sigreturn", and in there the kernel restores the state of the user mode stack, before returning to user space. It is possible to avoid the sigreturn system call by setting the sa_restorer field, and I don't know why Glibc 2.2 doesn't do this. By the way, the context stored on the stack is entirely a user space context, however it does include some information from the kernel that may be useful to user space, such as a page fault address. If the user space signal handler mucks with the context on its stack, all that happens is that "sigreturn" will end up restoring a different user space context and continuing execution with that. If you set context.eip to the address of the kernel's panic() function, than the user space program will simply crash with a SIGSEGV immediately after "sigreturn" returns to user space. Mucking with the context in a signal handler is even useful occasionally. enjoy, -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Why side-effects on open(2) are evil. (was Re: [RFD w/info-PATCH]device arguments from lookup)
Daniel Phillips <[EMAIL PROTECTED]> said:
> On Sunday 27 May 2001 15:32, Edgar Toernig wrote:
[...]
> > you break UNIX fundamentals. But I'm quite relieved now because I'm
> > pretty sure that something like that will never go into the kernel.
> OK, I'll take that as "I couldn't find a piece of code that breaks, so
> it's on to the legal issues".
It boggles my (perhaps underdeveloped) mind to have things that are files
_and_ directories at the same time. The last time this was discussed was
for handling forks (a la Mac et al) in files, and it was shot down.
> SUS doesn't seem to have a lot to say about this. The nearest thing to
> a ruling I found was "The special filename dot refers to the directory
> specified by its predecessor". Which is not the same thing as:
>
>open("foo", O_RDONLY) == open ("foo/.", O_RDONLY)
It says "foo" and "foo/." are the same _directory_, where "foo" is a
directory as otherwise "foo/" makes no sense, AFAICS. Is there
any mention on a _file_ "bar" and going "bar/" or "bar/"?
--
Horst von Brand [EMAIL PROTECTED]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: insl/outsl in parport_pc and !CONFIG_PCI
Richard Zidlicky wrote: > How is that supposed to work on systems without PCI? For now I have > defined > > #define insl(port,buf,len) isa_insb(port,buf,(len)<<2) > #define outsl(port,buf,len) isa_outsb(port,buf,(len)<<2) Tim, Fred, Will 4 * inb() cycles have the same effect as 1 * inl() cycle for an EPP mode read? By the way, it's probably worth a check whether insl() is actually faster than a loop doing inl() these days. Guess I should do that :) cheers, -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: ide dma timeout retry in pio
On Tue, 29 May 2001, Jens Axboe wrote: > This is bull shit. If IDE didn't muck around with the request so much in > the first place, the info could always be trusted. Even so, we have the > hard_* numbers to go by. So this argument does not hold. Maybe if you looked at the new code model as a whole you would see that the request-forking is gone. The object is to preserve a copy of the io instructions out to the registers to not have to repeat the do_request call unless it is a do or die thing. Also it is good to carry a copy of the local request even if it is never used. Also are you resetting the pointer (back to the geginning) on rq->buffer on the retry? You first flush the DMA engine and issue a device soft reset not using the current drive reset, is presevers the hwgroup->busy state and allows the request to be retried without reinserting. > > As I recall, there is a way to reinsert the faulted request, but that > > Again, look at the patch. The request is never off the list, so there is > never a reason to reinsert. hwgroup->busy is cleared (and, again for > good measure, hwgroup->rq), so ide_do_request/start_request will get the > same request that we just handled. I will have to poke in a few flags to verify this but if you say so. > > means the request_struct needs fault counter. If it is truly a DMA error > > ->errors, it's already there. Wrong location to poke and by that time it requires a full retry. The new code would have had the task structs filled with the error. > > because of re-seeks then the timeout value for that request must be > > expanded. > > Yep In some cases yes, but it would be better if I had a standard counter that meant something. Also changing the jiffie counter in ide_delay_50ms to a mdelay may have done more harm than good. 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/
bzdisk broken in 2.4.5?
I've tried on two separate machines to test out 2.4.5 through the "make bzdisk" boot floppy, and it fails on both (the compile succeeds, but boot never gets to LILO, it simply gives "400" and a repeating list of AX, BX, CX, and DX registers). Both are scsi aic7xxx, but use different controllers, and have scsi directly compiled in. One machine is based on RH 7.1 beta, the other on RH 7.1. Both are x86 SMP, with motherboard and all hardware being different. Using the same kernel through a "mkbootdisk" works, only "make bzdisk" fails. Can anyone here verify that "make bzdisk" will create a bootable floppy (I did try an entire box of different floppies) on 2.4.5+? Especially, can anyone verify this for SMP and/or purely scsi machines? If scsi, do you use aic7xxx? D. Stimits, [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: Copyright infringement in linux/drivers/usb/serial/keyspan*fw.h
James Sutherland wrote: > Note the "derived work"; there is no way on this earth (or any other) that > you could regard the device's firmware as being a "derived work" of the > driver! The same is true if you add another completely new and separately written .c source file: the new file is not a derived work of the driver. The GPL even has an explicit provision to make it clear that the GPL covers only the combined work, and the individual components continue to be available under their original terms. > AFAICS, the firmware is just a file served up to the device as needed > - no more a derivative work from the kernel than my homepage is a > derivative work of Apache. Indeed. But if you compiled your home page, linked it into Emacs to display on startup, and distributed the binary, the _combination_ "Emacs+homepage" binary would be a derived work, and you'd be required to offer source for both parts. It is the combination which is considered a derived work, and the GPL terms apply to a combination when any of the parts is GPLed. (Otherwise you aren't granted permission to distributed the combination). Combination, as ever, is different from "mere aggregation" and that's where so many arguments begin... -- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: how to crash 2.4.4 w/SBLive
On 28 May 2001 19:38:59 -0400, Bill Pringlemeir <[EMAIL PROTECTED]> wrote: >ps, There is no FAQ entry on how to generate a single object with `-g'. I >ended up recompiling my whole tree! I would say "read the source, Luke" but Makefile and Rules.make is so convoluted and twisted that it gives you a headache following the rule interactions. Edit drivers/sound/emu10k1/Makefile CFLAGS_timer.o += -g for one file or EXTRA_CFLAGS += -g for all files in the directory. With the 2.5 makefile rewrite you will be able to do make EXTRA_CFLAGS_drivers/sound/emu10k1.o=-g for just one file or make EXTRA_CFLAGS_drivers/sound=-g for all files in directory. No need to edit the Makefiles to set temporary flags, althought you can if you wish. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Potenitial security hole in the kernel
On Tue, May 29, 2001 at 01:30:30AM +0200, Kurt Roeckx wrote: > You should never "return" from userspace to kernelspace. The > only way to go from user space to kernel space should be by using > a system call. If you were able to return to kernel space, it already means you're running as kernel in the first place. There is no reason to even do the return in the first place. Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > Just to confirm this is what happening in your case: Can you please try > 2.4.4-ac5 and see if the _swap usage_ is still as badly? 2.4.4-ac5 seams to use the swap about as much as 2.4.4, which is less than 2.4.5-ac2. In my simple "freesly boot kernel, start X and Mozilla" test 2.4.4-ac5 showed almost identical 'free' output as 2.4.4: total used free sharedbuffers cached Mem: 62760 61368 1392 0 1828 28760 -/+ buffers/cache: 30780 31980 Swap: 160608 0 160608 > Back to the interactivity issue, I suppose you've "felt" bad interactivity > with 2.4.* kernels, right ? Yes, I feel bad interactivety with later 2.4.4-acX kernels, and 2.4.5 kernels. Switching between apps and such feels a lot slower. Let me know if you want me to do more tests. -- André Dahlqvist <[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: how to crash 2.4.4 w/SBLive
> "John" == John Lenton <[EMAIL PROTECTED]> writes:
John> I found to my dismay that it's extremely easy to crash 2.4.4 if
John> it has a Live! in it. I have no way of getting at the oops, but
John> somebody out there probably has both this soundcard and a
John> serial console (or somethin'). I present it in the form of a
John> script, but you'll probably have no problem realizing where the
John> problem is. The number of "writers" never gets past 64. I guess
John> the 65th should probably get the same as the 2nd writer does on
John> other cards...
I have retried this Oops with 2.4.4-ac17. I have the ksymoops'ed file.
The error is happening in "linux/drivers/sound/emu10k1/timer.c". The
function `emu10k1_timer_uninstall' has the following code,
list_del(&timer->list);
Which are the generic kernel list manipulation functions. The `next'
element is NULL and when the statement `next->prev = prev;' is
executed, the processor tries to access 4(NULL) in kernel mode. My
guess is that some sort of race condition is happening and `next' is
NULL when it shouldn't be; but what do I know...
Here is an objdump --disassemble --source --line...
174: fa cli
/usr/src/linux-2.4.4/include/linux/list.h:82
* the prev/next entries already!
*/
static __inline__ void __list_del(struct list_head * prev,
struct list_head * next)
{
175: 8b 52 04movl 0x4(%edx),%edx
178: 89 54 24 10 movl %edx,0x10(%esp,1)
17c: 8b 54 24 1c movl 0x1c(%esp,1),%edx
180: 8b 02 movl (%edx),%eax
/usr/src/linux-2.4.4/include/linux/list.h:83
next->prev = prev;
182: 8b 54 24 10 movl 0x10(%esp,1),%edx
186: 89 50 04movl %edx,0x4(%eax)
* Oops is here ^^
/usr/src/linux-2.4.4/include/linux/list.h:84
prev->next = next;
189: 89 02 movl %eax,(%edx)
/usr/src/linux-2.4.4/drivers/sound/emu10k1/timer.c:121
list_del(&timer->list);
list_for_each(entry, &card->timers) {
18b: 8b 97 70 40 00 00 movl 0x4070(%edi),%edx
191: 8d b7 70 40 00 00 leal 0x4070(%edi),%esi
I looked in list.h for a `safe' list delete, where next is checked for
NULL. Should the driver check this before calling `list_delete'?
Here is the opps again,
Unable to handle kernel NULL pointer dereference at virtual address 0004
printing eip: c01caa92
*pde =
Oops: 0002
CPU:0
EIP:0010:[emu10k1_timer_uninstall+50/236]
EFLAGS: 00010097
eax: ebx: ecx: c3a9350c edx:
esi: c11d8000 edi: c11d8000 ebp: 0097 esp: c3909f38
ds: 0018 es: 0018 ss: 0018
Process cat (pid: 872, stackpage=c3909000)
Stack: c3a93400 c11d8000 c2089ba0 c01c7957 c11d8000 c3a93478
c2089ba0 c3a93400 c11d8000 c01c78fa c2089ba0 0246 c3a93400 1000
c01c400a c2089ba0 ffea c15d6200 1000 1000 c3908000
Call Trace: [emu10k1_waveout_close+27/60]
[emu10k1_waveout_open+102/168]
[emu10k1_audio_write+190/456]
[sys_write+142/196]
[system_call+51/64]
Code: 89 50 04 89 02 8b 97 70 40 00 00 8d b7 70 40 00 00 89 54 24
And the script,
#!/bin/sh
setup () {
dd bs=1M count=10 /tmp/noise 2> /dev/null
}
noise () {
cat /tmp/noise > /dev/dsp &
}
setup
i=0
while (noise); do
i=$(( $i+1 ))
echo $i
done
thanks,
Bill
ps, There is no FAQ entry on how to generate a single object with `-g'. I
ended up recompiling my whole tree!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Dual Athlon Performance
On Mon, 28 May 2001, Jakob Østergaard wrote: > Please see the Beowulf mailing list (www.beowulf.org) - a dual athlon system > was tested there about a month ago, and various tests were collected and run. http://www.beowulf.org/pipermail/beowulf/ Archives for March and April conveniently missing. -Dan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
On Tue, May 29, 2001 at 12:12:56AM +0100, Russell King wrote: > On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote: > > Please correct me if i'm wrong but it seems to me that i've stumbled on > > really BIG security hole in the signal handling code. > > I don't think there's problem, unless I'm missing something. > > > The problem IMO is that the signal handling code stores a processor context > > on the user-mode stack frame which is active while > > the signal handler is running. > > User context (defined by 'regs') is stored onto the user stack. > However, when context is restored, certain checks are done, including > making sure that the segment registers cs and ss are their user mode > versions (or'd with 3), and the processor flags are non-privileged. If that's what's happening, I have to agree with him that there is a problem. Why would he need to go back to kernel space at all? He can make it point wherever he wants. You should never "return" from userspace to kernelspace. The only way to go from user space to kernel space should be by using a system call. Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Current tulip driver from 2.4.5 is plain broken
I mentioned that before but this should be stated clearly. As far as I am concerned "Linux Tulip driver version 0.9.15-pre2 (May 16, 2001)", as used in 2.4.5 - and other kernels - is totally buggered. It comes up, and ethernet interfaces can be configured, but does not matter how I am playing with options I cannot get a single packet through. Replacing it in 2.4.5 with "Linux Tulip driver version 0.9.14d (April 3, 2001)", which I have handy, restores sanity immediately and a network simply works without any heroic efforts. My NIC is "Digital DS21143 Tulip rev 65 at 0x8800". BTW - a version "tulip-1.1.7" from sourceforge behaves exactly like 0.9.15-pre2. This is an output of 'tulip-diag -af' from a working setup: tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0e000 0d572000 0d572200 f066 b2422002 fbfffbff 0x40: e000 fff583ff 52ca 0001 fffb 8ffd0008 Port selection is 10mpbs-serial, half-duplex. Transmit started, Receive started, half-duplex. The Rx process state is 'Waiting for packets'. The Tx process state is 'Idle'. The transmit threshold is 72. The NWay status register is 52ca. Internal autonegotiation state is 'Negotiation complete'. And this what shows up when I am trying to use "the-new-and-improved": tulip-diag.c:v2.06 1/8/2001 Donald Becker ([EMAIL PROTECTED]) http://www.scyld.com/diag/index.html Index #1: Found a Digital DS21143 Tulip adapter at 0x8800. Digital DS21143 Tulip chip registers at 0x8800: 0x00: f8a0d000 0b9f4000 0b9f4200 f000 b2420200 fbfffbff 0x40: e000 fff483ff 60ca 0001 fffb 8ffd Port selection is 10mpbs-serial, full-duplex. Transmit stopped, Receive stopped, full-duplex. The Rx process state is 'Stopped'. The Tx process state is 'Stopped'. The transmit threshold is 72. The NWay status register is 60ca. Internal autonegotiation state is 'Link check'. Comments? Michal [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: Potenitial security hole in the kernel
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote: > Please correct me if i'm wrong but it seems to me that i've stumbled on > really BIG security hole in the signal handling code. I don't think there's problem, unless I'm missing something. > The problem IMO is that the signal handling code stores a processor context > on the user-mode stack frame which is active while > the signal handler is running. User context (defined by 'regs') is stored onto the user stack. However, when context is restored, certain checks are done, including making sure that the segment registers cs and ss are their user mode versions (or'd with 3), and the processor flags are non-privileged. This means that when the kernel does eventually return to user space, if the user has pointed the EIP address at panic(), by the time we jump there the processor will not be in a privileged mode, and panic() won't do anything (you'll probably end up with a page fault caused by the processor fetching instructions from kernel space). However, that said, I don't know x86 in depth (I'm the ARM guy), so don't take this as gospel, but should be sufficient to point you in the right direction. (check the segment registers, check the eflags register, hell, try it out for real and see what happens)! -- Russell King ([EMAIL PROTECTED])The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
On Tue, May 29, 2001 at 12:30:03AM +0200, Vadim Lebedev wrote: > Kurt, > > Maybe i'm missing something but it seems that during execution of the signal > handler, user mode stack contains kernel mode context... > Hence the security hole It's rather complicated how things work. Both the user and kernel stack are changed. On the user stack we add a frame from the calling function. This just looks a function call. On the kernel stack we change the last frame so we "return" to the signal handler from the kernel. The signal handler then "returns" to the place where the process did the system call. You do not return to the kernel. I hope this helps you understand things better. Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: ide dma timeout retry in pio
On Tue, May 29, 2001 at 12:56:37AM +0200, Meelis Roos wrote: > LM> For what it is worth, in the recent postings I made about this topic, you > LM> suggested that it was bad cabling, I swapped the cabling, same problem. > LM> I swapped the mother board from Abit K7T to ASUS A7V and all cables worked > LM> fine. > > Similar info about KT7 - changing cables (both 30 and 80 wire) on Abit KT7 did > not help, still CRC errors (with all disks tried). So it looks like some KT7 > boards have problems with IDE interface cabling or smth. like that. I don't think it is a cabling problem, I think it is that motherboard. I suspect that the chipset on that motherboard is not well supported by Linux. As an aside, I am less than impressed with the IDE support in Linux. It's been a constant source of problems for the last couple of years and it doesn't seem to get fixed. We seem to get lots of chip sets almost working and then move on to the next one. -- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Broken memory init on VIA KX133
Alan Cox wrote: > > I'm wondering if anyone knows/has a fix for memory past 64mb not being > > detected (unless you use append="mem=...M" in lilo) on the Via VT8371 > > [KX133] North bridge. (Please CC any replies since I'm off kernel list > > atm.) > > Consult your BIOS vendor Actually, I just did some additional testing (as this was not an issue with FreebSD 4.2, Win2k, Win98 on the same hardware). The problem I describe was fixed in 2.2.19 -- where Linux now properly uses e820 instead of a legacy BIOS call to determine memory size. -- www.kuro5hin.org -- technology and culture, from the trenches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: ide dma timeout retry in pio
LM> For what it is worth, in the recent postings I made about this topic, you LM> suggested that it was bad cabling, I swapped the cabling, same problem. LM> I swapped the mother board from Abit K7T to ASUS A7V and all cables worked LM> fine. Similar info about KT7 - changing cables (both 30 and 80 wire) on Abit KT7 did not help, still CRC errors (with all disks tried). So it looks like some KT7 boards have problems with IDE interface cabling or smth. like that. -- Meelis Roos ([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: Linux 2.4.5-ac2
On Tue, 29 May 2001, André Dahlqvist wrote: > André Dahlqvist <[EMAIL PROTECTED]> wrote: > > > I agree. Kernels after 2.4.4 uses a *lot* more swap for me, which I guess > > might be part of the reason for the slowdown. > > Following up on myself, here are some numbers: > > Freshly booted 2.4.4 with X and Mozilla running, 'free' outputs this: > > total used free sharedbuffers cached > Mem: 62716 61280 1436 0 1820 28704 > -/+ buffers/cache: 30756 31960 > Swap: 160608 0 160608 > > Freshly booted 2.4.5-ac2 with X and Mozilla running, 'free' outputs this: > > total used free sharedbuffers cached > Mem: 62784 61784 1000380 1824 35748 > -/+ buffers/cache: 24212 38572 > Swap: 160608 7128 153480 > > After running 2.4.5-ac2 (and other kernels after vanilla 2.4.4) for a while > the swap usage grows a lot, to around 60 MB. Older kernels didn't swap out > this aggressively in my experience. Well, they probably did. Its just that the kernel released unused swap cache pages (thus releasing swap space) "more often". Just to confirm this is what happening in your case: Can you please try 2.4.4-ac5 and see if the _swap usage_ is still as badly? This kernel contains a workaround to make the VM release unused swap cache pages more often. (note: newer 2.4.4-ac do not contain the patch because it could cause locks under some cases. Specially swap to files) Back to the interactivity issue, I suppose you've "felt" bad interactivity with 2.4.* kernels, right ? I am asking that because I do not believe this swap usage issue is the main reason for the problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
> > Hi folks, > > Please correct me if i'm wrong but it seems to me that i've stumbled on > really BIG security hole in the signal handling code. > The problem IMO is that the signal handling code stores a processor context > on the user-mode stack frame which is active while > the signal handler is running. Then sys_sigreturn restores back the context > from user mode stack... > Suppose the signal handler modifies this context frame for example by > storing into the PC slot address of the panic routine > then when handler will exit panic will be called with obvious results. > > > Please CC your comments to me directly as i'm not subscibed to this list > > Vadim Lebedev > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Creative 4-speed CDROM driver
Where do I get this basic info on ATAPI? Will I benefit from the IDE standards document? Where can I get that? Thanks for your help - Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Alan Cox" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, May 28, 2001 11:21 PM Subject: Re: Creative 4-speed CDROM driver > > Unfortunately, I simply do not understand the code for device drivers that > > hackers have written. I don't know where to start and how to make sense of > > the code, to read it line by line and understand what it is doing. > > I think the minix book would be a good starting point. From the questions you > are asking you are rather out of your depth. Also some basic info on ATAPI > which is the protocol the CD-ROM devices use. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Potenitial security hole in the kernel
Kurt, Maybe i'm missing something but it seems that during execution of the signal handler, user mode stack contains kernel mode context... Hence the security hole Vadim - Original Message - From: "Kurt Roeckx" <[EMAIL PROTECTED]> To: "Vadim Lebedev" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 29, 2001 12:29 AM Subject: Re: Potenitial security hole in the kernel > On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote: > > Hi folks, > > > > Please correct me if i'm wrong but it seems to me that i've stumbled on > > really BIG security hole in the signal handling code. > > The problem IMO is that the signal handling code stores a processor context > > on the user-mode stack frame which is active while > > And how is that different from any other function call? > > > Kurt > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Potenitial security hole in the kernel
Philip, The point is the panic will be executed in KERNEL and NOT user mode. Unless i'm missing something the sigcontext contains kernel mode and not user mode context. Vadim - Original Message - From: "Philip Blundell" <[EMAIL PROTECTED]> To: "Vadim Lebedev" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 29, 2001 12:21 AM Subject: Re: Potenitial security hole in the kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Potenitial security hole in the kernel
On Mon, May 28, 2001 at 11:43:38PM +0200, Vadim Lebedev wrote: > Hi folks, > > Please correct me if i'm wrong but it seems to me that i've stumbled on > really BIG security hole in the signal handling code. > The problem IMO is that the signal handling code stores a processor context > on the user-mode stack frame which is active while And how is that different from any other function call? Kurt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Potenitial security hole in the kernel
>Suppose the signal handler modifies this context frame for example by >storing into the PC slot address of the panic routine >then when handler will exit panic will be called with obvious results. You can't execute panic() - or any other kernel function - in user mode. The application can write what it likes into its sigcontext, and the worst that will hapenn is that it will crash itself. p. PGP signature
Re: Creative 4-speed CDROM driver
Can you explain what this meas? Fake an SCSI device and use the SCSI driver to drive my CDROM? But what about the I/O port regions of memory, and the IRQ? Aren't they different? I am new to device drivers, I don't understand what I have to do. I know that I need to provide a service so I can mount my cdrom and use it, and that applications can read data from the /dev/cd0/whatever.file file on Minix. I need to know what the I/O hex memory area is, what IRQ to use, etc. I also need to know what functions I have to provide, like: open(filename, mode) read(fd, buffer, buffersize, flags) -- how to specify number of byts to read?? In the device driver code, I need to know what commands are for the ATAPI CDROM, or how I can do it as an SCSI like you say, like 0x30 put in I/O address whatever might be to query to see if there is a CD in the drive etc etc. This is very confusing. Would I benefit from reading the standards document you speak of? Where can I download a copy? How do I handle asynchronous I/O with a driver for a CDROM? Do I identify each user by the file descriptor when they issue a open() call, like in subsequent calls to read() they will pass the file descriptor, and I would have say a list of structures holding the file descriptor, offset where the last read() was, and so on, if so, what fields do I put in my structures and so on? As you can see, I am a newbie to device driver writing. ;) I am trying to learn by doing. Unfortunately, I simply do not understand the code for device drivers that hackers have written. I don't know where to start and how to make sense of the code, to read it line by line and understand what it is doing. I am going to take a look at the IDE CDROM driver code in Linux and see if I can modify the code to work as a device driver for Minix. Hope you can help me here, I'm really stuck! :-) Thanks Alan. I see that you are a prominent Linux developer and you know Linus. What device drivers have you written, or do you concentrate on the kernel proper? Cheers mate! James - Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, May 28, 2001 10:22 PM Subject: Re: Creative 4-speed CDROM driver > > If anyone on the kernel list has written a driver for a CDROM please send me > > mail about how you went about it, did you approach the manufacturer for the > > documentation on the device, if I made a mistake could I ruin my hardware? > > and stuff like that. > > For IDE CD-ROM there is a standard. Its about 600 pages long but the best > model is probably to implement scsi over atapi since Minix has some basic scsi > code. Then you can drive all but very old ide cdrom devices as scsi > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: ide dma timeout retry in pio
- Original Message - From: "Alan Cox" <[EMAIL PROTECTED]> To: "Mark Hahn" <[EMAIL PROTECTED]> Cc: "Jens Axboe" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, May 28, 2001 5:12 PM Subject: Re: [patch]: ide dma timeout retry in pio > > really? do we know the nature of the DMA engine problem well enough? > > I can categorise some of them: > > 1. Hardware that just doesnt support it. > 2. Timeouts that are false positives caused by disks having problems > and being very slow to recover > 3. Bad cabling > 4. Stalls caused by heavy PCI traffic > > > is there a reason to believe that it'll work better "later"? > > #1 will go fail, fail, fail -> PIO now (or should do Im about to try it) > #2 and #4 will be transient > #3 could go either way Where does the "'DMA Timeout -> disable DMA' then lose all responsiveness when I issue 'hdparm -d1' while it tries and fails to re-enable DMA" fit in? The disk will happily run for several days in UDMA33 and then at some point it craps out with a DMA timeout which results 1) DMA being turned off and 2) all attempts to re-enable DMA failing? And what's up with this: [root@MoveAlong james]# hdparm /dev/hda /dev/hda: multcount= 0 (off) I/O support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 1 (on) nowerr = 0 (off) readonly = 0 (off) readahead= 8 (on) geometry = 19590/16/63, sectors = 19746720, start = 0 [root@MoveAlong james]# hdparm -tT /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 6.98 seconds = 18.34 MB/sec Timing buffered disk reads: 64 MB in 5.77 seconds = 11.09 MB/sec Hmm.. suspicious results: probably not enough free memory for a proper test. [root@MoveAlong james]# free total used free sharedbuffers cached Mem:126800 123460 3340 0 67284 41572 -/+ buffers/cache: 14604 112196 Swap: 394624 32816 361808 I used to get ~33MB/sec on buffer-cache and ~10MB/sec on buffered disk reads in 2.2... --JT - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
André Dahlqvist <[EMAIL PROTECTED]> wrote: > I agree. Kernels after 2.4.4 uses a *lot* more swap for me, which I guess > might be part of the reason for the slowdown. Following up on myself, here are some numbers: Freshly booted 2.4.4 with X and Mozilla running, 'free' outputs this: total used free sharedbuffers cached Mem: 62716 61280 1436 0 1820 28704 -/+ buffers/cache: 30756 31960 Swap: 160608 0 160608 Freshly booted 2.4.5-ac2 with X and Mozilla running, 'free' outputs this: total used free sharedbuffers cached Mem: 62784 61784 1000380 1824 35748 -/+ buffers/cache: 24212 38572 Swap: 160608 7128 153480 After running 2.4.5-ac2 (and other kernels after vanilla 2.4.4) for a while the swap usage grows a lot, to around 60 MB. Older kernels didn't swap out this aggressively in my experience. This is on a 233 Mhz box with 64 megs of RAM. -- André Dahlqvist <[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/
Potenitial security hole in the kernel
Hi folks, Please correct me if i'm wrong but it seems to me that i've stumbled on really BIG security hole in the signal handling code. The problem IMO is that the signal handling code stores a processor context on the user-mode stack frame which is active while the signal handler is running. Then sys_sigreturn restores back the context from user mode stack... Suppose the signal handler modifies this context frame for example by storing into the PC slot address of the panic routine then when handler will exit panic will be called with obvious results. Please CC your comments to me directly as i'm not subscibed to this list Vadim Lebedev - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > It did not fixed any interactivity problem. I agree. Kernels after 2.4.4 uses a *lot* more swap for me, which I guess might be part of the reason for the slowdown. -- André Dahlqvist <[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: Broken memory init on VIA KX133
> I'm wondering if anyone knows/has a fix for memory past 64mb not being > detected (unless you use append="mem=...M" in lilo) on the Via VT8371 > [KX133] North bridge. (Please CC any replies since I'm off kernel list > atm.) Consult your BIOS vendor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Creative 4-speed CDROM driver
> If anyone on the kernel list has written a driver for a CDROM please send me > mail about how you went about it, did you approach the manufacturer for the > documentation on the device, if I made a mistake could I ruin my hardware? > and stuff like that. For IDE CD-ROM there is a standard. Its about 600 pages long but the best model is probably to implement scsi over atapi since Minix has some basic scsi code. Then you can drive all but very old ide cdrom devices as scsi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Broken memory init on VIA KX133
I'm wondering if anyone knows/has a fix for memory past 64mb not being detected (unless you use append="mem=...M" in lilo) on the Via VT8371 [KX133] North bridge. (Please CC any replies since I'm off kernel list atm.) -- www.kuro5hin.org -- technology and culture, from the trenches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 - ksymoops on Alpha - 2.4.5-ac3
Here is a trivial patch that will make ksymoops work again on Alpha.
--George
diff -urN linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c
linux/arch/alpha/kernel/traps.c
--- linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c Thu May 24 17:24:37 2001
+++ linux/arch/alpha/kernel/traps.c Mon May 28 16:38:25 2001
@@ -286,11 +286,7 @@
continue;
if (tmp >= (unsigned long) &_etext)
continue;
- /*
-* Assume that only the low 24-bits of a kernel text address
-* is interesting.
-*/
- printk("%6x%c", (int)tmp & 0xff, (++i % 11) ? ' ' : '\n');
+ printk("%16lx%c", tmp);
#if 0
if (i > 40) {
printk(" ...");
diff -urN linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c linux/arch/alpha/kernel/traps.c
--- linux-2.4.5-ac3-orig/arch/alpha/kernel/traps.c Thu May 24 17:24:37 2001
+++ linux/arch/alpha/kernel/traps.c Mon May 28 16:38:25 2001
@@ -286,11 +286,7 @@
continue;
if (tmp >= (unsigned long) &_etext)
continue;
- /*
- * Assume that only the low 24-bits of a kernel text address
- * is interesting.
- */
- printk("%6x%c", (int)tmp & 0xff, (++i % 11) ? ' ' : '\n');
+ printk("%16lx%c", tmp);
#if 0
if (i > 40) {
printk(" ...");
[PATCH] make kmalloc error return unconditional in hysdn_net.c (245ac1)
Hi.
The patch below fixes what I believe is a bug in hysdn_net.c.
I cannot see how we can proceed under _any_ circumstances
after the kmalloc fails. Applies against 245ac1.
--- linux-245-ac1-clean/drivers/isdn/hysdn/hysdn_net.c Sun May 27 22:15:22 2001
+++ linux-245-ac1/drivers/isdn/hysdn/hysdn_net.cMon May 28 22:44:16 2001
@@ -304,8 +304,7 @@
hysdn_net_release(card);/* release an existing net device */
if ((dev = kmalloc(sizeof(struct net_local), GFP_KERNEL)) == NULL) {
printk(KERN_WARNING "HYSDN: unable to allocate mem\n");
- if (card->debug_flags & LOG_NET_INIT)
- return (-ENOMEM);
+ return (-ENOMEM);
}
memset(dev, 0, sizeof(struct net_local)); /* clean the structure */
--
Regards,
Rasmus([EMAIL PROTECTED])
It has just been discovered that research causes cancer in rats.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5] buz.c won't compile
On Mon, May 28, 2001 at 03:15:04PM -0400, Ricky Beam wrote: > PS: I really hate it when people break "functional" things in the "stable" > tree. (functional and stable are both open to debate.) I was under the impression that it really wasn't functional. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [2.4.5] buz.c won't compile
>Actually, it broke at 2.4.3. Go look at the first change to buz.c from >that patch. None at all. It didn't break at 2.4.3, it just didn't compile at all anymore in 2.4.3. It was already kind of broken before that. >PS: I really hate it when people break "functional" things in the >"stable" >tree. (functional and stable are both open to debate.) Nobody broke it. The fact that it didn't compile right was something nobody ever looked at - it was already broken before and I really don't suppose anyone uses it. The words "if it compiles, it'll work" are not true. Really. Ronald PS, how about just removing it from the kernel? Would spare a lot of troubles, and nobody uses it anyway :-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
On Mon, 28 May 2001, Leeuw van der, Tim wrote: > The VM in 2.4.5 might be largely 'fixed' and I know that the VM changes in > -ac were considered to be but still broken, however for me they worked > better than what is in 2.4.5. The VM changes in 2.4.5 fixed a very serious performance problem. IMHO, 2.4.5 is a step in the right direction. (and I hope more steps are in the offing;) > I have a rather aging P5MMX at 200MHz with 64MB RAM, and I'm only judging > interactive use (not measuring anything like compile times etc). Interactive performance became a problem here exactly at the point when we stopped waiting for the vm to produce results. (which rather sucks, because that's also the spot where throughput improved [non-suprise]) -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: [patch]: ide dma timeout retry in pio
On Mon, May 28 2001, Mark Hahn wrote: > > request, when we hit a dma timout. In this case, what we really want to > > do is retry the request in pio mode and revert to normal dma operations > > later again. > > really? do we know the nature of the DMA engine problem well enough? > is there a reason to believe that it'll work better "later"? > I guess I was surprised at resorting to PIO - couldn't we just > break the request up into smaller chunks, still using DMA? That is indeed possible, it will require some surgery to the dma request path though. IDE has no concept of doing part of a request for dma currently, it's an all-or-nothing approach. That's why it falls back to pio right now. > I seem to recall Andre saying that the problem arises when the > ide DMA engine looses PCI arbitration during a burst. shorter > bursts would seem like the best workaround if this is the problem... It's worth a shot. My patch was not meant as the end-all solution, however we need something _now_. Loosing sectors is not funny. Dynamically limiting general request size for to make dma work is a piece of cake, that'll be about a one-liner addition to the current patch. So the logic could be something of the order of: - 1st dma timeout - scale max size down from 128kB (127.5kB really) to half that ... - things aren't working, 2nd dma timeout. Scale down to 32kB. and so forth, revert to pio and reset full size if it's really no good. If limiting transfer sizes solves the problem, this would be the way to go. I'll do another version that does this. Testers? Who has frequent ide dma timeout problems?? > resorting to PIO would be such a shame, not only because it eats > CPU so badly, but also because it has no checksum like UDMA... Look at the patch -- we resort to pio for _one_ hunk. That's 8 sectors tops, then back to dma. Hardly a big issue. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] remove unnecessary zero initializations from aironet4500_proc.c (245ac1)
(Forgot l-k again... :<)
- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
Hi.
The following patch removes two superfluous initializations
from aironet4500_proc.c, making the .o ~12K smaller in
size. It applies against 245ac1 and was discovered by Adam
Ritcher some time ago.
--- linux-245-ac1-clean/drivers/net/aironet4500_proc.c Sat May 19 20:58:24 2001
+++ linux-245-ac1/drivers/net/aironet4500_proc.cMon May 28 22:13:26 2001
@@ -59,7 +59,7 @@
charproc_name[10];
};
static char awc_drive_info[AWC_STR_SIZE]="Zcom \n\0";
-static char awc_proc_buff[AWC_STR_SIZE]="\0";
+static char awc_proc_buff[AWC_STR_SIZE];
static int awc_int_buff;
static struct awc_proc_private awc_proc_priv[MAX_AWCS];
@@ -403,7 +403,7 @@
{0}
};
-struct ctl_table_header * awc_driver_sysctl_header = NULL;
+struct ctl_table_header * awc_driver_sysctl_header;
const char awc_procname[]= "awc5";
--
Rasmus([EMAIL PROTECTED])
"If you aim the gun at your foot and pull the trigger, it's UNIX's job to
ensure reliable delivery of the bullet to where you aimed the gun (in
this case, Mr. Foot)." -- Terry Lambert, FreeBSD-Hackers mailing list.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] 4GB I/O, 2nd edition
On Mon, 28 May 2001, Jens Axboe wrote: > Hi, > > One minor bug found that would possibly oops if the SCSI pool ran out of > memory for the sg table and had to revert to a single segment request. > This should never happen, as the pool is sized after number of devices > and queue depth -- but it needed fixing anyway. > > Other changes: > > - Support cpqarray and cciss (two separate patches) > > - Cleanup IDE DMA on/off wrt highmem > > - Move run_task_queue back again in __wait_on_buffer. Need to look at > why this hurts performance. It decrease performance of what in which way ? 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/
2.4.5 and pppd/pppoe
Hello, I'm having problems with 2.4.5 and my pppoe connection. The kernel compiles fine, and works fine too, until I reboot, at which time it decides it no longer wants to work, and any time I attempt to call my start-pppoe script, i get: May 28 15:54:28 rocket pppd[3091]: pppd 2.4.1 started by root, uid 0 May 28 15:54:28 rocket pppd[3091]: Using interface ppp0 May 28 15:54:28 rocket pppd[3091]: Connect: ppp0 <--> /dev/ttyp0 May 28 15:54:43 rocket pppd[3091]: Hangup (SIGHUP) May 28 15:54:43 rocket pppd[3091]: Modem hangup May 28 15:54:43 rocket pppd[3091]: Connection terminated. May 28 15:54:44 rocket pppd[3091]: Exit. I am assuming that this is because of my eth0, which shows in ifconfig: eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 (it's using via-rhine chipset, compiled into kernel, not a module) This _only_ occurs after I reboot (ie. i can start up the new 2.4.5 kernel and work it perfectly once, then reboot and it doesnt work) Anybody have any ideas? Thanks, Daniel Rose - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
VIA KT133A Northbridge bug reported
I saw a report on AMDZone of another VIA chipset bug. The original source is:- http://www.chip.de/news_stories/news_stories_163106.html The claim from AMDZone's translation is that:- " According to the report KT133A boards with chipset codes of 1EA0 and 1EA4 can have the bug which causes your computer to restart." Has this one bitten Linuxers yet? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: unresolved symbols printk ?
On Mon, May 28, 2001 at 07:00:39PM +0200, Nico Schottelius wrote: > I am having problems with loading modules: > I always get the unresolved symbols message. > I didn't find any documentation for that, can you help me ? You did read question 8.8 from the linux-kernel mailing list FAQ? http://www.tux.org/lkml/#s8-8 Erik -- J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department of Electrical Engineering, Faculty of Information Technology and Systems, Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED] WWW: http://www-ict.its.tudelft.nl/~erik/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Creative 4-speed CDROM driver
Hello Kernel Hackers, Bloody Minix doesn't have a CDROM driver for my CDROM, a Creative Quad speed. I'm dual booting between Linux and Minix. Linux uses my CDROM no problems. I am thinking a "generic" CDROM driver might fit the bill for this CDROM (the system is an old 486DX2/66, 20MB RAM, 500MB HDD + 300MB HDD, 1MB Diamond Stealth Pro Video card). Either I can port the Linux CDROM driver to Minix or I have to write my own device driver. Can anyone help, point me to a place where hackers get the stuff they need to write device drivers? They obviously know all the details, like status codes, I/O regions etc. I am not sure if I would use DMA, but I suppose it doesn't matter all that much. If anyone on the kernel list has written a driver for a CDROM please send me mail about how you went about it, did you approach the manufacturer for the documentation on the device, if I made a mistake could I ruin my hardware? and stuff like that. Thanks heaps. James Buchanan [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/
Kernel 2.2: tq_scheduler functions scheduling and waiting
All: I have been diagnosing kernel panics for over a week and I have concerns with the use of tq_scheduler for which I was hoping I could get some assistance. Is it considered acceptable for functions in the tq_scheduler task list to call schedule? Is it acceptable for such functions to wait on wait queues? What limitations exist? As near as I can determine, the TTY driver code makes use of the tq_scheduler list for such purposes. In my testing, I am running with 96 TTY devices (talking to a high-density modem card) and I consistently achieve kernel panics when the system is under heavy swapping. I am continuing to diagnose the problem. The kernel panics are triggered mostly in goodness() and del_from_runqueue(), as indicated by ksym_oops and gdb, and I suspect the run queue is getting corrupted. In spite of this testing, I believe that I have an argument against tq_scheduler functions waiting on wait queues, but I have not thoroughly convinced myself that (a) this was not already known, and (b) this is already happening in existing kernel code. Any help is greatly appreciated. -art Arthur Naseef P.S. If this information is availed through existing documentation, searches, or other widely available resources, I would greatly appreciate references to this material. All of my searches to date have yielded few results and nothing definitive. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.4.5] buz.c won't compile
On Sat, 26 May 2001, Jan Sembera wrote: >i've got a problem compiling drivers/media/video/buz.c as module. When >i'm trying to compile, i get couple of errors: ... Actually, it broke at 2.4.3. Go look at the first change to buz.c from that patch. --Ricky PS: I really hate it when people break "functional" things in the "stable" tree. (functional and stable are both open to debate.) PPS: Yes, I know Linus doesn't bother compling most of the stuff :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac3 [address]
>From: Alan Cox <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Linux 2.4.5-ac3 >Date: Mon, 28 May 2001 17:49:23 +0100 Huh? What mail-address is this from? "[EMAIL PROTECTED]"? Guess I missed something? It's a nice one anyway ;-) Jonathan Brugge _ 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: File read.
On 28-May-2001 Mike Castle wrote: > On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote: >> >> On 28-Jun-2001 Anil Kumar wrote: >> > hi, >> > How do i read file within the kernel modules. I hope we can't use the FS >> > open... calls within kernel. >> >> You can access fs methods directly. > > But generally you don't want to. I usually don't but, you know, usually people like to know that they could ... - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: File read.
On Mon, May 28, 2001 at 11:26:31AM -0700, Davide Libenzi wrote: > > On 28-Jun-2001 Anil Kumar wrote: > > hi, > > How do i read file within the kernel modules. I hope we can't use the FS > > open... calls within kernel. > > You can access fs methods directly. But generally you don't want to. Use a user mode application to feed you the data instead. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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]: ide dma timeout retry in pio
Hi,
We have the current problem of ide dma possibly tossing out a complete
request, when we hit a dma timout. In this case, what we really want to
do is retry the request in pio mode and revert to normal dma operations
later again.
This patch catches the dma timout. It clears the dma engine, turns dma
off, sanity checks the request, and makes sure that the ide request
handler restarts the request (now in pio mode). When the first chunk of
the request is finished, return to dma mode. If the dma timeouts keep
happening, stay in pio mode.
Patch is untested for obvious reason, against 2.4.5-ac3
--
Jens Axboe
--- ../linux-2.4.5-ac3-clean/drivers/ide/ide.c Mon May 28 20:28:05 2001
+++ drivers/ide/ide.c Mon May 28 20:21:48 2001
@@ -543,10 +543,20 @@
{
struct request *rq;
unsigned long flags;
+ ide_drive_t *drive = hwgroup->drive;
spin_lock_irqsave(&io_request_lock, flags);
rq = hwgroup->rq;
+ /*
+* decide whether to reenable DMA -- 3 is a random magic for now,
+* if we DMA timeout more than 3 times, just stay in PIO
+*/
+ if (drive->state == DMA_PIO_RETRY && drive->retry_pio <= 3) {
+ drive->state = 0;
+ hwgroup->hwif->dmaproc(ide_dma_on, drive);
+ }
+
if (!end_that_request_first(rq, uptodate, hwgroup->drive->name)) {
add_blkdev_randomness(MAJOR(rq->rq_dev));
blkdev_dequeue_request(rq);
@@ -1419,6 +1429,49 @@
}
/*
+ * un-busy the hwgroup etc, and clear any pending DMA status. we want to
+ * retry the current request in pio mode instead of risking tossing it
+ * all away
+ */
+void ide_dma_timeout_retry(ide_drive_t *drive)
+{
+ ide_hwif_t *hwif = HWIF(drive);
+ struct request *rq;
+
+ /*
+* end current dma transaction
+*/
+ (void) hwif->dmaproc(ide_dma_end, drive);
+
+ /*
+* complain a little, later we might remove some of this verbosity
+*/
+ printk("%s: timeout waiting for DMA\n", drive->name);
+ (void) hwif->dmaproc(ide_dma_timeout, drive);
+
+ /*
+* disable dma for now, but remember that we did so because of
+* a timeout -- we'll reenable after we finish this next request
+* (or rather the first chunk of it) in pio.
+*/
+ drive->retry_pio++;
+ drive->state = DMA_PIO_RETRY;
+ (void) hwif->dmaproc(ide_dma_off_quietly, drive);
+
+ /*
+* un-busy drive etc (hwgroup->busy is cleared on return) and
+* make sure request is sane
+*/
+ rq = HWGROUP(drive)->rq;
+ HWGROUP(drive)->rq = NULL;
+
+ rq->errors = 0;
+ rq->sector = rq->bh->b_rsector;
+ rq->current_nr_sectors = rq->bh->b_size >> 9;
+ rq->buffer = rq->bh->b_data;
+}
+
+/*
* ide_timer_expiry() is our timeout function for all drive operations.
* But note that it can also be invoked as a result of a "sleep" operation
* triggered by the mod_timer() call in ide_do_request.
@@ -1491,11 +1544,10 @@
startstop = handler(drive);
} else {
if (drive->waiting_for_dma) {
- (void) hwgroup->hwif->dmaproc(ide_dma_end,
drive);
- printk("%s: timeout waiting for DMA\n",
drive->name);
- (void) hwgroup->hwif->dmaproc(ide_dma_timeout,
drive);
- }
- startstop = ide_error(drive, "irq timeout",
GET_STAT());
+ startstop = ide_stopped;
+ ide_dma_timeout_retry(drive);
+ } else
+ startstop = ide_error(drive, "irq timeout",
+GET_STAT());
}
set_recovery_timer(hwif);
drive->service_time = jiffies - drive->service_start;
--- ../linux-2.4.5-ac3-clean/include/linux/ide.hMon May 28 20:28:13 2001
+++ include/linux/ide.h Mon May 28 20:21:18 2001
@@ -87,6 +87,11 @@
#define ERROR_RECAL1 /* Recalibrate every 2nd retry */
/*
+ * state flags
+ */
+#define DMA_PIO_RETRY 1 /* retrying in PIO */
+
+/*
* Ensure that various configuration flags have compatible settings
*/
#ifdef REALLY_SLOW_IO
@@ -299,6 +304,8 @@
special_t special;/* special action flags */
byte keep_settings; /* restore settings after drive reset */
byte using_dma; /* disk is using dma for read/write */
+ byte retry_pio; /* retrying dma capable host in pio */
+ byte state; /* retry state */
byte waiting_for_dma; /* dma currently in progress */
byte unmask;/* flag: okay to unmask other irqs */
byte slow;
RE: File read.
On 28-Jun-2001 Anil Kumar wrote: > hi, > How do i read file within the kernel modules. I hope we can't use the FS > open... calls within kernel. You can access fs methods directly. Look at this newbie article : http://www.linux-mag.com/2000-11/gear_01.html - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loopback crypt.
Is there any way to delete the key of an existing loopback encrypted device, and have it block, until a key is reloaded? Of course any cached pages would need deleted, and dirty ones flushed first. To enable things like deleting keys from memory, before suspend-to-disk, or forcing users of devices to verify identitiy, on various events. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.5: SCSI devices are mixed up?
Hi folks, It took me quite some time to recognize what has changed between 2.4.4 and 2.4.5 and why my CD drives were not accessable: Somehow the sequence of SCSI devices has been changed. For 2.4.4 the IDE SCSI emulation was scsibus0, my Adaptec 39160 was scsibus1 and scsibus2. Suddenly with 2.4.5 the IDE SCSI stuff is scsibus2. The Adaptec devices moved down one step. You can imagine that this mixed up a lot of things. Fortunately my boot disk wasn't affected. My question is: How can I specify the sequence of the SCSI devices? I would like to make sure that this doesn't happen again. Regards Harri - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [SOLVED] PROBLEM: Alpha SMP Low Outbound Bandwidth
On Monday 28 May 2001 13:45, Jay Thorne wrote: > Problem solved, thanks to the rawhide patch from Richard Henderson > ([EMAIL PROTECTED]) posted on Sunday. Performance is ~10megs/second both > directions, using tulip, de4x5 or via-rhine. Well Done, Richard. > > Using 2.4.4-ac15 it works fine. I'm now trying 2.4.5 > > Andrea, 2.4.5aa1 oopses just after probing the scsi cards. I've tried > the 2.4.4 series aa patches and had similar failure on boot. > > Its too fast to see the error, so I'm building a serial console version > to capture it. Is an easy way to tell an alpha to stop dead so I can > copy the oops? try adding 'console=ttyS0,9600 console=tty0' to the comand line args passed to the kernel at boot time. if you are using SRM and aboot, 'b -fl i' followed by the 'l' command, then a 'b' command. regards, --George - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
what is the diffence between main_table and local_table?
Hello! When I look at the source about route in linux,I find the definition of main_table and local_table. What is the difference between them. Thanks! _ ÊýÂë²úÆ·ÐÂÉÏÊУ¬¿á http://shopping.263.net/category21.htm ¾«Æ·Ð¡¼ÒµçÓÏÄÈÈÂô http://shopping.263.net/category23.htm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[SOLVED] PROBLEM: Alpha SMP Low Outbound Bandwidth
Problem solved, thanks to the rawhide patch from Richard Henderson ([EMAIL PROTECTED]) posted on Sunday. Performance is ~10megs/second both directions, using tulip, de4x5 or via-rhine. Using 2.4.4-ac15 it works fine. I'm now trying 2.4.5 Andrea, 2.4.5aa1 oopses just after probing the scsi cards. I've tried the 2.4.4 series aa patches and had similar failure on boot. Its too fast to see the error, so I'm building a serial console version to capture it. Is an easy way to tell an alpha to stop dead so I can copy the oops? On 25 May 2001 23:16:34 -0400, George France wrote: > Hello Andrea, > > Jay, if the problem still exist in 2.4.5-pre6aa1 (please try the new kernel), > then I will have tech op's check this on Tuesday (Monday is a US holiday). > We should be able to duplicate this in the hardware lab and find the problem > with a logic analyser. > > Best Regards, > > > --George > > On Friday 25 May 2001 20:51, Andrea Arcangeli wrote: > > On Fri, May 25, 2001 at 05:25:03PM -0700, Jay Thorne wrote: > > > But Wu-ftpd is an easy to set up test bench, and is ubiquitous enough > > > that anyone with an alpha running SMP can test it. Note that this > > > > My smp alpha box drives a single tulip over 12MB/sec in full duplex > > using tcp without any problem at all. So I definitely cannot reproduce. > > You may want to try to reproduce with 2.4.5pre6aa1 btw. If you've not > > tried it yet you can consider also using egcs 1.1.2 as compiler just in > > case. > > > > You may also want to keep an eye on the VM, on alpha I see very weird > > things happening. > > > > 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/ -- -- Jay Thorne Manager, Systems & Technology, UserFriendly Media, Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] fix more typos in Configure.help and fs/nls/Config.in
The ISO639 registrars call it "Belarusian". See http://lcweb.loc.gov/standards/iso639-2/langhome.html under "English Name of Language". Against 2.4.5-ac2: --- Configure.help.orig Mon May 28 19:23:18 2001 +++ Configure.help Mon May 28 19:31:50 2001 @@ -12838,7 +12838,7 @@ only, not to the file contents. You can include several codepages; say Y here if you want to include the DOS codepage for Thai. -Windows CP1251 (Bulgarian, Belarussian) +Windows CP1251 (Bulgarian, Belarusian) CONFIG_NLS_CODEPAGE_1251 The Microsoft FAT file system family can deal with filenames in native language character sets. These character sets are stored in @@ -12847,7 +12847,7 @@ DOS/Windows partitions correctly. This does apply to the filenames only, not to the file contents. You can include several codepages; say Y here if you want to include the DOS codepage for Russian and - Bulgarian and Belarussian. + Bulgarian and Belarusian. Japanese charsets (Shift-JIS, EUC-JP) CONFIG_NLS_CODEPAGE_932 @@ -12938,7 +12938,7 @@ from the Microsoft FAT file system family or from JOLIET CDROMs correctly on the screen, you need to include the appropriate input/output character sets. Say Y here for ISO8859-5, a Cyrillic - character set with which you can type Bulgarian, Byelorussian, + character set with which you can type Bulgarian, Belarusian, Macedonian, Russian, Serbian, and Ukrainian. Note that the charset KOI8-R is preferred in Russia. @@ -13027,13 +13027,13 @@ input/output character sets. Say Y here for the preferred Russian character set. -NLS KOI8-U/RU (Ukrainian, Belarussian) +NLS KOI8-U/RU (Ukrainian, Belarusian) CONFIG_NLS_KOI8_U If you want to display filenames with native language characters from the Microsoft FAT file system family or from JOLIET CDROMs correctly on the screen, you need to include the appropriate input/output character sets. Say Y here for the preferred Ukrainian - (koi8-u) and Belarussian (koi8-ru) character sets. + (koi8-u) and Belarusian (koi8-ru) character sets. NLS UTF8 CONFIG_NLS_UTF8 @@ -19014,7 +19014,7 @@ # LocalWords: prio Micom xIO dwmw rimi OMIRR omirr omirrd unicode ntfs cmu NIC # LocalWords: Braam braam Schmidt's freiburg nls codepages codepage Romanian # LocalWords: Slovak Slovenian Sorbian Nordic iso Catalan Faeroese Galician SZ -# LocalWords: Valencian Slovene Esperanto Estonian Latvian Byelorussian KOI mt +# LocalWords: Valencian Slovene Esperanto Estonian Latvian Belarusian KOI mt # LocalWords: charset Inuit Greenlandic Sami Lappish koi Alexey Kuznetsov's sa # LocalWords: Specialix specialix DTR RTS RTSCTS cycladesZ Exabyte ftape's inr # LocalWords: Iomega's LBFM claus ZFTAPE VFS zftape zft William's lzrw DFLT kb --- Config.in.orig Sun May 27 00:10:50 2001 +++ Config.in Mon May 28 19:32:25 2001 @@ -29,7 +29,7 @@ tristate 'Codepage 852 (Central/Eastern Europe)' CONFIG_NLS_CODEPAGE_852 tristate 'Codepage 855 (Cyrillic)' CONFIG_NLS_CODEPAGE_855 tristate 'Codepage 857 (Turkish)'CONFIG_NLS_CODEPAGE_857 - tristate 'Codepage 860 (Portugese)' CONFIG_NLS_CODEPAGE_860 + tristate 'Codepage 860 (Portuguese)' CONFIG_NLS_CODEPAGE_860 tristate 'Codepage 861 (Icelandic)' CONFIG_NLS_CODEPAGE_861 tristate 'Codepage 862 (Hebrew)' CONFIG_NLS_CODEPAGE_862 tristate 'Codepage 863 (Canadian French)'CONFIG_NLS_CODEPAGE_863 @@ -43,7 +43,7 @@ tristate 'Korean charset (CP949, EUC-KR)'CONFIG_NLS_CODEPAGE_949 tristate 'Thai charset (CP874, TIS-620)' CONFIG_NLS_CODEPAGE_874 tristate 'Hebrew charsets (ISO-8859-8, CP1255)' CONFIG_NLS_ISO8859_8 - tristate 'Windows CP1251 (Bulgarian, Belarussian)' CONFIG_NLS_CODEPAGE_1251 + tristate 'Windows CP1251 (Bulgarian, Belarusian)' CONFIG_NLS_CODEPAGE_1251 tristate 'NLS ISO 8859-1 (Latin 1; Western European Languages)' CONFIG_NLS_ISO8859_1 tristate 'NLS ISO 8859-2 (Latin 2; Slavic/Central European Languages)' CONFIG_NLS_ISO8859_2 tristate 'NLS ISO 8859-3 (Latin 3; Esperanto, Galician, Maltese, Turkish)' CONFIG_NLS_ISO8859_3 @@ -56,7 +56,7 @@ tristate 'NLS ISO 8859-14 (Latin 8; Celtic)' CONFIG_NLS_ISO8859_14 tristate 'NLS ISO 8859-15 (Latin 9; Western European Languages with Euro)' CONFIG_NLS_ISO8859_15 tristate 'NLS KOI8-R (Russian)' CONFIG_NLS_KOI8_R - tristate 'NLS KOI8-U/RU (Ukrainian, Belarussian)' CONFIG_NLS_KOI8_U + tristate 'NLS KOI8-U/RU (Ukrainian, Belarusian)' CONFIG_NLS_KOI8_U tristate 'NLS UTF8' CONFIG_NLS_UTF8 endmenu fi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
aha152x problem
Hello! I tried to load thie aha152x modules: modprobe aha152x io=0x140 irq=9 (which is correct) entries in /proc/scsi are generated, but the modprobe hangs and is unkillable. aha152x reports scsi discs to the kernel messages, although there are none connected to it. I tried to use a scanner, but it it impossible to work with the controller. Did I miss any patches/ fixes ? Nico using 2.4.4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
unresolved symbols printk ?
Hello! I am having problems with loading modules: I always get the unresolved symbols message. I didn't find any documentation for that, can you help me ? What I did: compiled 2.4.4; installed modules. depmod -ae -F /usr/src/linux/System.map 2.4.4 runs fine, depmod -a doesn't run fine (unresolved symbols) modprobe any_module results in unresolved modules message. modutils are 2.4.2. Any ideas what I did wrong ? Sincerly, Nico - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux 2.4.5-ac3
ftp://ftp.kernel.org/pub/linux/kernel/people/alan/2.4/ Intermediate diffs are available from http://www.bzimage.org In terms of going through the code audit almost all the sound drivers still need fixing to lock against format changes during a read/write. Poll creating and starting a buffer as write does and also mmap during write, write during an mmap. 2.4.5-ac3 o Ignore console writes from an IRQ handler (me) o Make SIGBUS/SIGILL visible to UML debugger (Jeff Dike) o Clean up UML syscalls add missing items (Jeff Dike) o Clean up non portable UML code (Jeff Dike) o Fix off by one and other oddments in hostfs (Henrik Nordstrom) o Update UML to use CONFIG_SMP not __SMP__(Jeff Dike) o Fix UML crash if console is typed at too early (Jeff Dike) o Clean up UML host transports(Lennert Buytenhek, Jim Leu) o Resynchronize UML/ppc (Chris Emerson) o Fix UML crash if it had an address space hole (Jeff Dike) between text and data o Fix rd_ioctl crash with initrd (Go Taniguchi) o Fix IRQ ack path on Alpha rawhide (Richard Henderson) o Drop back to older 8139too driver from 2.4.3 | Seems the new one causes lockups o Experimental promise fastrak raid driver(Arjan van de Ven) 2.4.5-ac2 o Restore lock_kernel on umount (Al Viro) | Should cure Reiserfs crash in 2.4.5 o Fix additional scsi_ioctl leak (John Martin) o Clean up scsi_ioctl error handling (me) o Configure.help typo fixes (Nerijus Baliunas) o Fix hgafb problems with logos (Ferenc Bakonyi) o Fix lock problems in the rio driver (Rasmus Andersen) o Make new cmpci SMP safe (Carlos E Gorges) o Fix missing restore flags in soundmodem (Rasmus Andersen) o Set max sectors in ps2esdi (Paul Gortmaker) o Fix interrupt restore problems in mixcom(Rasmus Andersen) o Fix alpha compile on dp264/generic (Andrea Arcangeli) o Fix irda irport locking restores(Rasmus Andersen) o Fix failed kmalloc handling in hisax(Kai Germaschewski) o Add missing memory barrier in qlogicisp (?) o Fix missing restore_flags in eata_dma (Rasmus Andersen) o Fix procfs locking in irttp (Rasmus Andersen) o Winbond updates (Manfred Spraul) o Stop network eating PF_MEMALLOC ram (Manfred Spraul) o Drop fs/buffer.c low mem flush changes (me) o Drop changes to mm/highmem.c(me) | I don't think the Linus one is quite right but its easier | for everyone to be working off one base o Revert GFP_FAIL and some other alloc bits (me) o Hopefully fix initrd problem(me) o Fix kmalloc check in ide-tape (Rasmus Andersen) o Fix irda irtty locking (Rasmus Andersen) o Fix missing irq restore in qla1280 (Rasmus Andersen) o Fix proc/pid/mem cross exec behaviour (Arjan van de Ven) o Fix direct user space derefs in eicon (me) | From Stanford checker o Fix direct user space derefs in ipddp (me) | From Stanford checker o Fix direct user space derefs in ixj (me) | From Stanford checker o Fix direct user space derefs in decnet (me) | From Stanford checker 2.4.5-ac1 o Merge Linus 2.4.5 tree Summary of changes for Linux 2.4.5-ac versus Linus 2.4.5 o Fix memory leak in wanrouter o Fix memory leak in wanmain o Use non atomic memory for linearising NFS buffers as they are done in task context o Fix dereference of freed memory in NetROM drivers o Fix writing to freed memory in ax25_ip o Support debugging of slab pools o NinjaSCSI pcmcia scsi driver o Raw HID device for USB peripheral buttons/controllers o Updated NTFS o RAMfs with resource limits o NMI watchdog available on uniprocessor x86 o Update CMPCI drivers (not yet SMP safe) o Configurable max_map_count o Dynamic sysctl key registration o SE401 USB camera driver o Updated Zoran ZR3606x driver (replaces buz) o w9966 parallel port camera driver (partially merged with Linus) o Include headers in etags o Don't delete empty directories on make distclean o Fix halt/reboot handling on Alcor Alpha o IDE driver support for Etrax E100 o
Re: [PATCH] Documentation/kernel-docs.txt
Oops, that was wrong. The proper patch is: --- Documentation/kernel-docs.txt.old Mon May 28 12:06:43 2001 +++ Documentation/kernel-docs.txt Mon May 28 12:37:26 2001 @@ -333,7 +333,8 @@ * Title: "The Kernel Hacking HOWTO" Author: Various Talented People, and Rusty. - URL: http://www.samba.org/~netfilter/kernel-hacking-HOWTO.html + URL: http://netfilter.gnumonks.org/unreliable-guides/kernel-hacking/ + lk-hacking-guide.html Keywords: HOWTO, kernel contexts, deadlock, locking, modules, symbols, return conventions. Description: From the Introduction: "Please understand that I @@ -393,9 +394,8 @@ * Title: "Linux Kernel Locking HOWTO" Author: Various Talented People, and Rusty. - URL: - http://netfilter.kernelnotes.org/unreliable-guides/kernel-locking- - HOWTO.html + URL: http://netfilter.gnumonks.org/unreliable-guides/kernel-locking/ + lklockingguide.html Keywords: locks, locking, spinlock, semaphore, atomic, race condition, bottom halves, tasklets, softirqs. Description: The title says it all: document describing the - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
FW: Linux 2.4.5-ac2
-Original Message- From: Alan Cox [mailto:[EMAIL PROTECTED]] Sent: Monday, May 28, 2001 12:20 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Linux 2.4.5-ac2 > But the claim was that 2.4.5-ac2 is faster than 2.4.5 plain, so which > changes are in 2.4.5-ac2 that would make it faster than 2.4.5 plain? Also, I > don't know if 2.4.5-ac1 is as fast as 2.4.5-ac2 for Fabio. If not, then it's > a change in the 2.4.5-ac2 changelog. If it is as fast, it is one of the > changes in the 2.4.5-ac1 changelog. ac1 to ac2 backs out some of the bits of old VM cruft. ac2 doesnt really add much that is VM relevant but it might be the user has a VIA chipset box in which case -ac will be faster for other reasons - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4.5-ac2
> But the claim was that 2.4.5-ac2 is faster than 2.4.5 plain, so which > changes are in 2.4.5-ac2 that would make it faster than 2.4.5 plain? Also, I > don't know if 2.4.5-ac1 is as fast as 2.4.5-ac2 for Fabio. If not, then it's > a change in the 2.4.5-ac2 changelog. If it is as fast, it is one of the > changes in the 2.4.5-ac1 changelog. ac1 to ac2 backs out some of the bits of old VM cruft. ac2 doesnt really add much that is VM relevant but it might be the user has a VIA chipset box in which case -ac will be faster for other reasons - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Matrox G400 Dualhead
The problem reported here before was switching from X to the console. The video signal would be lost and the computer would hang. The responses pointed out the it was the switch of video modes; XFree would change the internals of the video controller which the frame buffer could not cope with. You were part of the discussion. The matrox drivers have not changed since april, so its interactions with the frame buffer may be still buggy. -- Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Status of ALi MAGiK 1 support in 2.4.?
On Mon, May 28, 2001 at 05:57:12PM +0200, Axel Thimm wrote: > What is the status of the support for this chipset, found for example in an > ASUS A7A266? Judging from > http://www.acerlabs.com/eng/support/faqlnx.htm > one gets the impression that ALi is respectfully treating the Linux community. I cannot answer your question about the level of support this chipset has, but suffice it to say that my new (as of last week) A7A266 based system (1.2Ghz T-Bird w/256MB Crucial DDR RAM) is running 2.4.5 (and previous to that 2.2.18) quite nicely. Perhaps Linux is not optimized for performance with this chipset, but it feels fast to me. According to 'hdparm -t /dev/hda', I am getting 25MB/s transfer rates with my Quantum Fireball Plus LM. Seems a little high, but drive performance 'feels' good. Based on my weekend experience with this board and Linux, I think I have made the right choice. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 difference between Linus's kernel and Alan Cox's kernel
Em Sex 25 Mai 2001 20:05, Alan Cox escreveu: > > Why there are two different kernel trees? There is always the official > > release, provided by Torvalds, and then Alan provides a patch merging > > Linus's stuff, and adding (?) tons of bug fixes. > > Well it started by accident but it turns out good to have a tree that > changes are merged into, tested by those who need the fixes and reviewed by > third parties before they go to Linus. > > So the -ac tree is kind of a peer review, testing and distillation process > for patches. But will this happen forever? You (Alan) is currently the maintaner of the 2.2 tree. Won't you be going to assume the 2.4 tree, while the 2.5 series development starts? BTW, Thanks for your answer. Regards, -- Thiago Vinhas de Moraes NetWorx - A SuaCompanhia.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/
incorrect help for NETLINK in 2.2.19
Hi all, I think I've found some incorrect helptexts in 2.2.19: I've compared the netlink config options for 2.2.19 with 2.4.5. 1. CONFIG_NETLINK - Enabling netlink The help in 2.4.5 seems correct to me. 2.2.19 raves about nodes under /dev with major 36. (BAD) 2. CONFIG_RTNETLINK - Route messages over netlink. 2.4.5 seems good here too. 2.2.19 tells us to create a /dev/route node.(BAD) 3. CONFIG_NETLINK_DEV - Enable support for major 36 nodes. 2.4.5 says that this option enables major 36 nodes. 2.2.19 says nothing useful at all. (BAD) CONFIG_NETLINK_DEV enables major 36 char devices for both 2.2 and 2.4, right? If that is true then I suggest that the 2.4.5-help for NETLINK is used for next 2.2-kernel. And - the help for CONFIG_RTNETLINK claims that data sent to the kernel is ignored. Is that really true? Tell me if you want a patch. Thanks / Magnus Damm http://opensource.se - open source in sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
