Repeatable hard locks on console switch. XFree 4.1.0
Dear All; I can fire up XFree4.1.0 on one or several virtual consoles, and switch between them, and text consoles to my hearts content. However, if the X server exits everything is still fine, _except_ any attempt to switch consoles at this point will lock up the machine completely. (eg. numlock doesnt work, nor does magic sysrq, unpingable, no logs) [ Trivially the problem manifests itself when one logs in via xdm, then logs out. You can log back on just fine, but if you try to switch virtual consoles after this it locks.] XFree3.3.6 works good for me. XFree4.1.0 manifests the problem on 2.4.5, and 2.2.18. I128 server. Any comments or suggestions welcome Thanks; Paul [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: memory usage - dentry_cacheg
Marcin Kowalski <[EMAIL PROTECTED]>, on Thu Apr 12, 2001 [05:30:59 PM] said: > Hi > > I have applied this(Tom's) patch as well as the small change to > dcache.c(thanx Andreas, David, Alexander and All), I ran some tests and so > far so good, both the dcache and inode cache entries in slabinfo are keeping > nice and low even though I tested by creating thousands of files and then > deleting then. The dentry and icache both pruged succesfully. > I applied these patches to 2.4.3-ac5, and it made a world of difference. I can run kernel compiles, things like 'find /', and move between desktops running netscape, mutt with 15000 messages threaded, etc. without sloggy delays... eg. previously netscape used to take a second or so to repaint under this type of 'load' upon returning to it from a brief visit to another desktop. This is a subjective assesment of my desktop type system, k6-333 with 64M; 2.4 is much more usable for me now. If anyone wants me to run specific tests, I am willing. Paul [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/
[oops] 2.2.17 + ide + pcsnd
U: AMD-K6(tm) 3D processor stepping 00 Checking 386/387 coupling... OK, FPU using exception 16 error reporting. Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX PCI: PCI BIOS revision 2.10 entry at 0xf0560 PCI: Using configuration type 1 PCI: Probing PCI hardware Linux NET4.0 for Linux 2.2 Based upon Swansea University Computer Society NET3.039 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP TCP: Hash tables configured (ehash 131072 bhash 65536) Starting kswapd v 1.5 Serial driver version 4.27 with no serial options enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A ttyS03 at 0x02e8 (irq = 0) is a 16550A Real Time Clock Driver v1.09 PCSP 1.3 measurement: maximal samplerate 149147 Hz, 18356 Hz used Uniform Multi-Platform E-IDE driver Revision: 6.30 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ALI15X3: IDE controller on PCI bus 00 dev 78 ALI15X3: chipset revision 193 ALI15X3: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xd400-0xd407, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd408-0xd40f, BIOS settings: hdc:DMA, hdd:pio hda: Maxtor 71336 A, ATA DISK drive ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hdc: WDC AC36400L, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: Maxtor 71336 A, 1277MB w/64kB Cache, CHS=2595/16/63, DMA hdc: WDC AC36400L, 6149MB w/256kB Cache, CHS=13328/15/63, UDMA(33) Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 wd.c:v1.10 9/23/94 Donald Becker ([EMAIL PROTECTED]) eth0: WD80x3 at 0x300, 00 00 C0 47 8A 29 WD8013, IRQ 11, shared memory at 0xd-0xd3fff. Partition check: hda: hda1 hda2 hda3 hdc: hdc1 hdc2 hdc3 hdc4 VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 44k freed kmod: runaway modprobe loop assumed and stopped NET4: Unix domain sockets 1.0 for Linux NET4.0. Adding Swap: 152608k swap-space (priority 3) CSLIP: code copyright 1989 Regents of the University of California PPP: version 2.3.7 (demand dialling) PPP line discipline registered. PPP BSD Compression module registered PPP Deflate Compression module registered IPv6 v0.8 for NET4.0 IPv6 over IPv4 tunneling driver irqtune/0.4: setting system IRQ priority to 3/14 eth0: no IPv6 routers present PCSP on device 3, mixer on device 0 =-=-=-=-=-=-=-=-=- -- Versions installed: (if some fields are empty or looks -- unusual then possibly you have very old versions) Linux squish 2.2.17 #139 Sun Oct 8 21:34:25 EDT 2000 i586 AuthenticAMD Kernel modules 2.1.121 Gnu C 2.95.2 Binutils 2.9.1.0.25 Linux C Library2.1.2 Dynamic linker ldd: version 1.9.10 Procps 2.0.2 Mount 2.9r Net-tools 1.52 Console-tools 0.2.3 Sh-utils 1.16 Modules Loaded pcsnd soundcore nfs lockd sunrpc ipv6 ip_masq_ftp ppp_deflate bsd_comp ppp slhc unix =-=-=-=-=-=-=-=-=- Paul [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[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: Inconsistent "#ifdef __KERNEL__" on different architectures
Adrian Bunk writes: > (my main concern wasn't whether the "#ifdef __KERNEL__" is correct or not > but I was wondering whether there's a reason why it's different on > different architectures) The only valid reason for userspace programs to be including kernel headers is to get definitions that are part of the kernel API. (And in fact others here will go further and assert that there are *no* valid reasons for userspace programs to include kernel headers.) If you want some atomic functions or whatever for your userspace program and the ones in the kernel look like they would be useful, then take a copy of the relevant kernel code if you like, but don't include the kernel headers directly. If you do, you will get bitten at some point in the future when we decide to change some internal implementation detail in the kernel, and your program suddenly won't compile any more. This is why I added #ifdef __KERNEL__ around most of the contents of include/asm-ppc/*.h. It was done deliberately to flush out those programs which are depending on kernel headers when they shouldn't. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Inconsistent "#ifdef __KERNEL__" on different architectures
Adrian Bunk writes: > Whatever the right policy is, the main concern in my initial mail was the > _consistency_ of the kernel headers between different architectures. > So when you want to flush out these programs I see no reason to > inconsistetly change it only on one architecture. Different architectures are maintained by different people who have different perspectives on things. The only thing you have any right to expect any consistency in is the kernel API, and even there things like error numbers etc. differ between architectures. If you want consistency, you would either have to persuade Linus to issue an edict or else persuade every single architecture maintainer to do things the same way. But if the motivation is to make it easier for user-level programs to use things which are not intended to be exported to userspace, then all you will achieve is that we will make sure that you can't use those things from userspace. And this definitely includes things like atomics, bitops, memory barriers etc. Take a copy by all means but don't rely on the kernel definitions for your userspace programs. It is the policy for all architectures that kernel headers should not be used in userspace programs. The "inconsistency" that you are complaining about is only a difference in the extent to which this policy is enforced. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: temperature standard - global config option?
> Kernel is worldwide, should not use anlo-saxon shifted units. Use the > International System of Units (SI) > http://physics.nist.gov/cuu/Units/units.html Hmmm... I don't see bogomips on this list! :-) Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.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/
InterprocessCommunication
Hi all I need to know some basic facts about interprocess communication. I have a process A which is waiting for some other process B. When B is executed, it has to wake up A and do some work with A. How to do this. I think it will be better to use signals. 1 How to use signals 2 Is there any other ideas other than signals 3 It is better if u send some sample codes by Blesson Paul Get free email and a permanent address at http://www.netaddress.com/?N=1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Large ramdisk crashes system
I am trying to create a system which boots off of a cd and has no hard disks. So it needs ramdisks. But I haven't had much luck creating large ones. I tried on two different boxes. In both cases the kernel is 2.4.5 with 'Simple RAM-based file system support' turned on. One box is a dual Pentium 750 with a gig of ram in it. I had the kernel 'Default RAM disk size' set to 80 for this box. I issued the following commands. mkfs /dev/ram0 40 mount /dev/ram0 /mnt dd if=/dev/zero of=/mnt/junk bs=1024 count=50 This is fine, dd creates a 400 meg file, reports there isn't enough space and exits. But if I change the first line to mkfs /dev/ram0 50 I'm essentially crashed. I can ping the box and switch between virtual terminals but that's it. Any program that was running on the other virtual terminals is frozen (as in top, tail, login). The dd is frozen and can't be control-c'd. so I can't do anything other than powercycle. I should have at least 400 megs of ram left for the system so I don't get it. I tried the same thing on a 128 meg box. The results were similar. A 40 meg ram disk worked. A 60 meg ram disk crashed the box. The numbers seem a little odd since in both cases the magic threshold seems to be roughly 40% of ram. I get no messages in the system logfiles nor an oops on the screen. Any ideas? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] panic in scsi_free/sr_scatter_pad
Jens Axboe wrote: > > On Tue, May 29 2001, Paul Gortmaker wrote: > > 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 > > Here's a better patch, it also gets the freeing right. It's been fixed > for long, just haven't been sent to Linus yet. It's in Alan's tree, and > in fact I think I've send it to this list more than once :) Ok, essentially same patch - good to see. Seems old rule of thumb[1] for linux patches still applies :) I see you opted for a new var. to store old use_sg value, rather than make use of SCpnt->old_use_sg like I did. Was curious as to your reasoning for that - maybe I'm overlooking something. Other thing that crossed my mind was the appropriateness of scsi_free() doing a panic. For this particular case, a BUG() would have been more informative if we were relying on info in a bug report from Joe Average to solve the problem. (Also, panic is a bit harsh if say CD is only SCSI device and everything else is EIDE, but scsi_free has no way of knowing...) Paul. [1] Odds are somebody has already posted the patch you just finished... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Large ramdisk crashes system
On Fri, 8 Jun 2001, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > the kernel is 2.4.5 with 'Simple RAM-based file system support' turned on. > > > I issued the following commands. > > > mkfs /dev/ram0 40 > > mount /dev/ram0 /mnt > > dd if=/dev/zero of=/mnt/junk bs=1024 count=50 > > Why turn on ramfs if you're not going to use it? > Actually I experimented with both ext2 and ramfs, getting similar results. I forgot to mention that in the post though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Large ramdisk crashes system
On Thu, 7 Jun 2001, Marcelo Tosatti wrote: > On Thu, 7 Jun 2001, Paul Buder wrote: > > > I am trying to create a system which boots off of a cd and has no hard > > disks. So it needs ramdisks. But I haven't had much luck creating > > large ones. [ explanation of large ram disks crashing the system edited out for brevity] > > Can you get the (traced by ksymoops) backtrace of dd and kswapd > everything is locked? > > You can do that with sysrq. I copied the sysreq-t screen to paper and then typed it up and fed it to ksymoops. I get some errors since this kernel has module support turned off. I also get a message from ksymoops saying Warning (Oops_read): Code line not seen, dumping what data is available which I'm not sure of the meaning. So anyway, my oops file and the output from ksymoops follow. Hopefully I've done this right. If there is anything else I can provide let me know. kswapdR f7d5abfc 0 3 1(L-TLB) 4 2 Call Trace: c010fd6b>] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] ddR current 756 249 187(NOTLB) Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] ksymoops 2.4.1 on i686 2.4.5. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.5/ (default) -m /usr/src/linux/System.map (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed No modules in ksyms, skipping objects No ksyms, skipping lsmod Call Trace: c010fd6b>] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; c010fd6b Trace; c010e526 Trace; c01247e4 Trace; c01247e4 Trace; c010e030 Trace; c01247e4 Trace; c010deab Trace; c01260aa Trace; c0126115 Trace; c0126299 Trace; c0126349 Trace; c01263dc Trace; c011153f Trace; c012727d Trace; c0127459 Trace; c01274d2 Trace; c012753b Trace; c01056d0 Trace; c015c184 Trace; c01964c1 Trace; c019ddab Trace; c019d804 Trace; c0194799 Trace; c01974f2 Trace; c011043e Trace; c012e4e5 <__wait_on_buffer+85/94> Trace; c0173b8b <__make_request+15b/6bc> Trace; c0173bbf <__make_request+18f/6bc> Trace; c0173bd9 <__make_request+1a9/6bc> Trace; c01964c1 Trace; c019ddab Trace; c019d804 Trace; c0197499 Trace; c01974f2 Trace; c020e742 Trace; c01e81b0 Trace; c020956b Trace; c01df693 Trace; c01d923d Trace; c01e8253 Trace; c01df143 Trace; c01e6da2 Trace; c01e81b0 Trace; c01e81a9 Trace; c01df143 Trace; c01e7a5f Trace; c01e819c Trace; c0201c1c Trace; c0201a2c Trace; c0201c30 Trace; c0202322 Trace; c017184c Trace; c016be8f Trace; c016b159 Trace; c01150ea Trace; c012f88a Trace; c017184c Trace; c01c5df0 Trace; c0167ff2 Trace; c016b464 Trace; c0112d86 Trace; c0112d86 Trace; f880 Trace; c01071d8 Trace; c01071d8 Trace; c0107207 Trace; c0111033 Trace; c01110ee Trace; c017307f Trace; c0171747 Trace; c01728bd Trace; c0172948 Trace; c01085f0 Trace; c01087d7 Trace; c0106f40 Trace; c021ce04 Trace; c0122880 Trace; c012d7aa Trace; c0106e67 1 warning and 1 error issued. Results may not be reliable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Race between sys_swapon and /proc/swaps (2.4)
sys_swapon() sets SWP_USED in p->flags when it begins to set up a swap
area, and then calls vmalloc() to allocate p->swap_map[], which may
sleep. Most other users of the swap info structures either traverse the
swap list (to which the new swap area hasn't yet been added) or check
SWP_WRITEOK (which hasn't yet been set), but get_swaparea_info() only
checks for SWP_USED, and then proceeds to dereference ptr->swap_map. So
reading /proc/swaps whilst doing a swapon() can Oops.
This could either be solved by making get_swaparea_info() check for
ptr->swap_map, or check for ((ptr->flags & SWP_WRITEOK) == SWP_WRITEOK).
The patch below (applicable to 2.4.5 - patch for 2.2 in following email)
checks for the former on the grounds that that is what's causing the
immediate problem, and some people might want to be able to use
/proc/swaps to track the progress of a swapoff().
Paul
diff -Naur linux/mm/swapfile.c linux.new/mm/swapfile.c
--- linux/mm/swapfile.cWed Apr 11 21:59:56 2001
+++ linux.new/mm/swapfile.c Fri Jun 8 17:18:32 2001
@@ -503,7 +503,7 @@
len += sprintf(buf, "Filename\t\t\tType\t\tSize\tUsed\tPriority\n");
for (i = 0 ; i < nr_swapfiles ; i++, ptr++) {
- if (ptr->flags & SWP_USED) {
+ if ((ptr->flags & SWP_USED) && ptr->swap_map) {
char * path = d_path(ptr->swap_file, ptr->swap_vfsmnt,
page, PAGE_SIZE);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Race between sys_swapon and /proc/swaps (2.2)
This is the equivalent patch for Linux 2.2 (prepared against 2.2.19)
for the swapon/procfs race also described in my previous email.
sys_swapon() sets SWP_USED in p->flags when it begins to set up a swap
area, and then calls vmalloc() to allocate p->swap_map[], which may
sleep. Most other users of the swap info structures either traverse the
swap list (to which the new swap area hasn't yet been added) or check
SWP_WRITEOK (which hasn't yet been set), but get_swaparea_info() only
checks for SWP_USED, and then proceeds to dereference ptr->swap_map. So
reading /proc/swaps whilst doing a swapon() can Oops.
This could either be solved by making get_swaparea_info() check for
ptr->swap_map, or check for ((ptr->flags & SWP_WRITEOK) == SWP_WRITEOK).
The patch below (applicable to 2.2 - patch for 2.4 in previous email)
checks for the former on the grounds that that is what's causing the
immediate problem, and some people might want to be able to use
/proc/swaps to track the progress of a swapoff().
Paul
diff -u linux/mm/swapfile.c linux/mm/swapfile.c
--- linux/mm/swapfile.cWed May 9 23:34:24 2001
+++ linux.new/mm/swapfile.c Fri Jun 8 17:00:54 2001
@@ -448,7 +448,7 @@
len += sprintf(buf, "Filename\t\t\tType\t\tSize\tUsed\tPriority\n");
for (i = 0 ; i < nr_swapfiles ; i++, ptr++) {
- if (ptr->flags & SWP_USED) {
+ if ((ptr->flags & SWP_USED) && ptr->swap_map) {
char * path = d_path(ptr->swap_file, page, PAGE_SIZE);
len += sprintf(buf + len, "%-31s ", path);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Inode quota allocation loophole (2.4)
Currently, dquot_initialize() is a no-op if the inode being initialized
isn't a regular file, directory or symlink. This means that calling
DQUOT_ALLOC_INODE() on a named pipe or AF_UNIX socket has no effect (the
same applies to devices, but this is less likely to be a problem as
random users can't create them); as a result a user can exhaust the
filesystem's inodes even when they have a quota limit. This problem is
exploitable in 2.2.19 and 2.4.2, and appears to be present in all kernel
versions that I've looked at.
I presume that the reason for not putting quotas on pipes and sockets is
that it's slightly more efficient not to do so. If that's the case, then
the simplest solution would be to remove the checks in fs/dquot.c (patch
below for 2.4.5 - patch for 2.2 in following email). Are there any
undesirable consequences to pipes, sockets and devices having non-NULL
pointers in i_dquot[]?
Paul
--- linux/fs/dquot.cSun May 20 11:32:11 2001
+++ linux.new/fs/dquot.cTue Jun 12 00:39:50 2001
@@ -651,8 +651,6 @@
{
int cnt;
-if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
S_ISLNK(inode->i_mode)))
-return 0;
if (is_quotafile(inode))
return 0;
if (type != -1)
@@ -1022,9 +1020,6 @@
unsigned int id = 0;
short cnt;
- if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode) &&
-!S_ISLNK(inode->i_mode))
- return;
lock_kernel();
/* We don't want to have quotas on quota files - nasty deadlocks possible */
if (is_quotafile(inode)) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Inode quota allocation loophole (2.2)
This is the equivalent patch for Linux 2.2 (prepared against 2.2.19) for
the quota loophole described in my previous email.
Currently, dquot_initialize() is a no-op if the inode being initialized
isn't a regular file, directory or symlink. This means that calling
DQUOT_ALLOC_INODE() on a named pipe or AF_UNIX socket has no effect (the
same applies to devices, but this is less likely to be a problem as
random users can't create them); as a result a user can exhaust the
filesystem's inodes even when they have a quota limit. This problem is
exploitable in 2.2.19 and 2.4.2, and appears to be present in all kernel
versions that I've looked at.
I presume that the reason for not putting quotas on pipes and sockets is
that it's slightly more efficient not to do so. If that's the case, then
the simplest solution would be to remove the checks in fs/dquot.c (patch
below for 2.2 - patch for 2.4 in my earlier email). Are there any
undesirable consequences to pipes, sockets and devices having non-NULL
pointers in i_dquot[]?
Paul
--- linux/fs/dquot.cSun May 20 11:32:11 2001
+++ linux.new/fs/dquot.cTue Jun 12 00:39:50 2001
@@ -667,8 +667,6 @@
{
int cnt;
-if (!(S_ISREG(inode->i_mode) || S_ISDIR(inode->i_mode) ||
S_ISLNK(inode->i_mode)))
-return 0;
if (is_quotafile(inode))
return 0;
if (type != -1)
@@ -1082,38 +1078,34 @@
unsigned int id = 0;
short cnt;
- if (S_ISREG(inode->i_mode) ||
-S_ISDIR(inode->i_mode) ||
-S_ISLNK(inode->i_mode)) {
- /* We don't want to have quotas on quota files - nasty deadlocks
possible */
- if (is_quotafile(inode))
- return;
- for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
- if (type != -1 && cnt != type)
+ /* We don't want to have quotas on quota files - nasty deadlocks possible */
+ if (is_quotafile(inode))
+ return;
+ for (cnt = 0; cnt < MAXQUOTAS; cnt++) {
+ if (type != -1 && cnt != type)
+ continue;
+
+ if (!sb_has_quota_enabled(inode->i_sb, cnt))
+ continue;
+
+ if (inode->i_dquot[cnt] == NODQUOT) {
+ switch (cnt) {
+ case USRQUOTA:
+ id = inode->i_uid;
+ break;
+ case GRPQUOTA:
+ id = inode->i_gid;
+ break;
+ }
+ dquot = dqget(inode->i_dev, id, cnt);
+ if (dquot == NODQUOT)
continue;
-
- if (!sb_has_quota_enabled(inode->i_sb, cnt))
+ if (inode->i_dquot[cnt] != NODQUOT) {
+ dqput(dquot);
continue;
-
- if (inode->i_dquot[cnt] == NODQUOT) {
- switch (cnt) {
- case USRQUOTA:
- id = inode->i_uid;
- break;
- case GRPQUOTA:
- id = inode->i_gid;
- break;
- }
- dquot = dqget(inode->i_dev, id, cnt);
- if (dquot == NODQUOT)
- continue;
- if (inode->i_dquot[cnt] != NODQUOT) {
- dqput(dquot);
- continue;
- }
- inode->i_dquot[cnt] = dquot;
- inode->i_flags |= S_QUOTA;
- }
+ }
+ inode->i_dquot[cnt] = dquot;
+ inode->i_flags |= S_QUOTA;
}
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
inetd missing
hi I just brought a CD of RedHat 7. Unfortunately I couldn't find the inetd rpm. wheather it is missing or it is in any other name by Blesson Get free email and a permanent address at http://www.netaddress.com/?N=1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SyncPPP Generic PPP merge
From: "Alan Cox" <[EMAIL PROTECTED]> > I had hoped for 2.4 to use generic ppp with it. That might be the more > productive way to attack the problem. Generic PPP requires the user mode pppd to handle the LCP and NCPs, while syncppp implements these in the kernel. Instead of using ifconfig to bring an interface up or down, the user must now work with pppd. And the net device naming changes (allocated by ppp_generic.c instead of using the net device allocated by low level driver). I have no problem with this, but some people might not be happy with the change. Is the plan to *replace* the PPP code in syncppp (hopefully in a way that is invisible to the low level drivers)? Or is it to *add* generic PPP support to syncppp, leaving (at least temporarily) the existing PPP capability in syncppp for compatibility? (implying a new syncppp flag USE_GENERIC_PPP?) Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.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/
Kernel 2.0.35 limits
Just this morning, our firewall get a kernel panic after 500 days of uptime. As you can see from the log files, the date starts at June 15th, where we get two div by zeros, then jumps May 11th, then a kernel panic. A reboot brings it back to June 15th. Since cron could not open /dev/rtc. My first thought was an internal kernel limit on the time, but 500 days seems a bit short. Any ideas ? Last message via e-mail was: Date: Fri, 15 Jun 2001 08:01:05 -0400 To: [EMAIL PROTECTED] From: Cron Daemon <[EMAIL PROTECTED]> Subject: Cron run-parts /etc/cron.hourly Unable to open /dev/rtc, open() errno = Device or resource busy (16) The log file has: ... Jun 15 08:01:13 tap PAM_pwdb[3491]: (su) session opened for user nobody by (uid=99) Jun 15 08:01:16 tap kernel: divide error: Jun 15 08:01:16 tap kernel: CPU:0 Jun 15 08:01:16 tap kernel: EIP:0010:[do_fast_gettimeoffset+71/120] Jun 15 08:01:16 tap kernel: EFLAGS: 00013002 Jun 15 08:01:16 tap kernel: eax: 0ccabc7c ebx: 01ea65e1 ecx: 0017 edx: 00146440 Jun 15 08:01:16 tap kernel: esi: eb72aa0f edi: ebp: bbd4 esp: 00718f88 Jun 15 08:01:16 tap kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Jun 15 08:01:16 tap kernel: Process hwclock (pid: 3495, process nr: 63, stackpage=00718000) Jun 15 08:01:16 tap kernel: Stack: 00718fb0 3246 0001 001109d6 bb3c 00117e08 00718fb0 Jun 15 08:01:16 tap kernel:00a84414 bea8 3b29f90c 7530 0010a989 bb3c Jun 15 08:01:16 tap kernel:bea8 0001 bbd4 ffda 002b 002b 002b 002b Jun 15 08:01:16 tap kernel: Call Trace: [do_gettimeofday+34/68] [sys_gettimeofday+44/112] [system_call+85/124] Jun 15 08:01:16 tap kernel: Code: f7 f1 ba 10 27 00 00 89 c1 31 c0 f7 f1 a3 e4 03 1d 00 89 c3 Jun 15 08:01:16 tap kernel: divide error: Jun 15 08:01:16 tap kernel: CPU:0 Jun 15 08:01:16 tap kernel: EIP:0010:[do_fast_gettimeoffset+71/120] Jun 15 08:01:16 tap kernel: EFLAGS: 00010002 Jun 15 08:01:16 tap kernel: eax: 0cf383d2 ebx: 01ea65e1 ecx: 0019 edx: 00146440 Jun 15 08:01:16 tap kernel: esi: eb9b7165 edi: ebp: bbd4 esp: 00ba1f88 Jun 15 08:01:16 tap kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Jun 15 08:01:16 tap kernel: Process hwclock (pid: 3509, process nr: 26, stackpage=00ba1000) Jun 15 08:01:16 tap kernel: Stack: 00ba1fb0 0246 3b29f90b 001109d6 bb2c 00117e08 00ba1fb0 Jun 15 08:01:16 tap kernel:00842c0c 3b29f90c 3b29f90c c350 0010a989 bb2c 0001 Jun 15 08:01:16 tap kernel:3b29f90c 3b29f90b bbd4 ffda 002b 002b 002b 002b ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 7829 now 7829. May 11 07:52:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. May 11 07:53:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. May 11 07:54:29 tap kernel: eth2: No link beat on the MII interface, status then 7829 now 7829. Jun 15 10:33:39 tap kernel: klogd 1.3-3, log source = /proc/kmsg started. Jun 15 10:33:40 tap kernel: Loaded 4215 symbols from /boot/System.map. Jun 15 10:33:40 tap kernel: Symbols match kernel version 2.0.35. ... Thank You. -- Paul N. Faure 613.266.3286 Chief Technical Officer, CertainKey Inc.[EMAIL PROTECTED] Carleton University Systems Eng. 3rd Year [EMAIL PROTECTED] Engineering Society Administrator [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: any good diff merging utility?
Ivan Vadovic writes: > Well, are there any utilities to merge diffs? I couldn't find any on freshmeat. > So what are you using to stack many patches onto the kernel tree? Just manualy > modify the diff? I'll try to write something more automatic if nothing comes up. Try dirdiff - ftp://ftp.samba.org/pub/paulus/dirdiff-1.2.tar.gz. I use it all the time for merging in changes between Linus' official tree, my own development tree, and the PPC/Linux bitkeeper trees. Dirdiff is a tcl/tk-based utility for graphically displaying the difference between directory trees. It can handle from 2 to 5 trees. It displays a main window where it shows which files are different. You can select a file and get it to show the diffs between that file in any two of the directory trees. This comes up in another window in a format like a unified diff but with the background of the line colored according to which file it comes from. You can also copy files between trees with a menu item - in fact you can select whole groups of files to be copied. And you can use it to generate patches too. :) Once you have the differences between two versions of a file displayed, you can do a merge between the two versions. Each line of differences has a little check box beside it. If you check the box it means you want to make that change (right-click or shift-click selects a whole group of boxes). When you have checked all the boxes you want you select an item from the merge menu to say which tree you want to update. The new version of the file comes up in an edit window and you can check it, make any further changes you want, etc. Then you can either save the result or close the window (discarding the merge). It's hard to explain in words everything about how it works and how you use it. It isn't really a utility to merge diffs but it is very useful in tracking and merging changes between several large source trees. I find it particularly useful because I am usually interested only in a subset of the files (i.e. particularly arch/ppc and include/asm-ppc). So when Linus releases a new pre-patch, I update my "official Linus source" tree and do another dirdiff. If there are changes to files under fs/ for instance, I just select all of them and copy them over to my tree without looking at the diffs. If there are changes in arch/i386 for instance, I look at the diff to see if I am going to need to make a similar change in arch/ppc. Regards, Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/PPC maintainer changing
Cort has put in an enormous amount of time and effort into maintaining the PowerPC port of Linux over the past 5 or 6 years, and I for one would like to acknowledge that publicly and thank him for that. It has not always been an easy task, I know, because there are a wide range of opinions within the PPC/Linux camp and Cort has been the man on the spot to sort out the balance between the competing interests. And I for one will miss the time, effort and resources he has put into the infrastructure things such as the repository, web pages, ftp site etc. I would also like to thank FSM Labs for contributing the space and bandwidth for the PPC/Linux repository over the last couple of years. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sis630 - help needed debugging in the kernel
On Mon, Jun 18, 2001 at 08:32:03PM +0200, René Rebe wrote: > > Try booting at 640x480 with a color depth of 32. Then > > try booting at a different resolution (1024x768) at the default color > > depth. I want to see if its a error with the resolution setting or if it > > is a error with setting up the data relating to the color depth handling. > > The results should give me some clue. > > I can't set the videomode for the driver ...? I tried: > > video=sis:vesa:0x112 > video=sis:xres:640,yres:480,depth:32 > video=sis,xres:640,yres:480,depth:32 > > Is there another way to tell the fb driver what mode to use?? > Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". Also, the driver requires that the mode is passed video a "mode:" argument as is outlined in the sisfb_setup(). Take a look at drivers/video/sis/sis_main.h, specifically sisbios_mode[] for a list of supported modes. Something like: video=sisfb:mode:640x480x32 should do the job. Regards, -- Paul Mundt <[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: sis630 - help needed debugging in the kernel
On Mon, Jun 18, 2001 at 02:58:17PM -0700, James Simmons wrote: > > Yep, in fbmem.c the name entry is "sisfb" as opposed to just "sis". > > Agh!!! That needs to be fixed. > I've already fixed it in ruby.. Regards, -- Paul Mundt <[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/
RPC vs Socket
hi all I am in the way of building a new remote file system. Presently I decided to use sockets for remote communication. Lately I understood that RPC is used in coda and nfs file systems(is it so). I want to know the fessibility in using RPC in the new file system. by Blesson Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: The latest Microsoft FUD. This time from BillG, himself.
Alan Cox wrote: > > http://www.zdnet.com/zdnn/stories/news/0,4586,5092935,00.html > > > Of course the URL that goes with that is : > http://www.microsoft.com/windows2000/interix/features.asp > > Yes., Microsoft ship GNU C (quite legally) as part of their offerings... Do they include the source? There's a CD of source that you can buy for $20 but gcc isn't listed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
Chip Salzenberg wrote: > > This is a 2.2.17pre20 refresh of the /proc/config.gz patch [...] > +include/linux/config_data.h: newversion scripts/bin2c > + gzip -9 < .config | scripts/bin2c kernel_config_data > $@ > + If you are going to store options the kernel was built with, you might as well get rid of all the cruft so you don't run into size problems. For example: sed '/=m/d;s/=y//;/^CONFIG_/s///p;d' .config |\ gzip -9 | scripts/bin2c kernel_config_data > $@ maintains all the useful information and will be less than 1/2kB. (things marked as not set or modular aren't relevant to the zImage) You can reconstruct it back with: gzip -d < /proc/config.gz | sed '/=/\!s/$/=y/;s/^/CONFIG_/' > .config Run 'make oldconfig' and hold down the Enter key for a few seconds. Paul. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Paul Jakma wrote: > May i suggest the following: > > cp System.map /boot/System.map- or even better cp to /lib/modules// and fix the tools to look there if they don't do already. --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2: /proc/config.gz
On Thu, 31 Aug 2000, Robert Greimel wrote: > It would be nice if "make modules_install" would automatically copy System.map > to /lib/modules// . > as well as .config to /lib/modules//config. (i had to meant to write .config not System.map originally as that is what the thread is about... doh!) whatever, there's no need for kernel memory to bloated out with .config. > Greetings > > Robert > --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On 1 Sep 2000, Matthias Andree wrote: > Alan Cox <[EMAIL PROTECTED]> writes: > Well, I'm asking again, as usual, are you planning to integrate > kernel-space NFSv3? I'd appreciate if you did. yes please. 0: The new NFS patches work so so much better than vanilla linux nfs. 1: due to (0) most dists have actually been distributing the patches and updated userland for a v. long time now! 2: incompatible tools: those who follow a dist are already using incompatible tools anyway, and can either stay with their dist or get the neccessary tools themselves (nfs-utils is available in RPM and deb anyway!). those who follow the stock kernel can read the changes file. please please lets sort out NFS in 2.2! (cause it's going to be around for a good while yet). Any pain it may cause in tool updates is completely mitigated by the stability, performance and interoperability benefits of the the patches. regards, -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: "Are you sure you're not an encyclopedia salesman?" No, Ma'am. Just a burglar, come to ransack the flat." -- Monty Python - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On Fri, 1 Sep 2000, Neil Brown wrote: > What incompatible tools??? > > Any nfs-utils that work with vanilla 2.2.16 will work just fine with > patched 2.2.16. They may not access any new functionality, but there > ARE NO INCOMPATIBILITIES (that I know of, and I am quute close to the > game). > i meant old tools. sorry. will old tools work with kernel+nfs patches? i think the fear and main argument against updating NFS in linux 2.2 is that people will be forced to update their tools. (however to that arg i say: anybody who uses NFS for any half serious purpose will already have patched up, or is using a dist kernel with patches). > Note that this is in contrast to the changes that went into 2.2.14, > which DID break compatability - all of a sudden you needed to run > lockd from user space, where as before you didn't. (with the patches > you don't any more, so they actaully improve compatability). > cool. another reason to include the patches. > NeilBrown > > -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: I try to keep an open mind, but not so open that my brains fall out. -- Judge Harold T. Stone - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On Fri, 1 Sep 2000, Alan Cox wrote: > I'd love to have raid 0.90, nfsv3 and the new ide stuff in but I > cannot see a path for that without breaking a supposedly stable > product for other people which is simply not acceptable. > raid i can understand considering it's a 'no way back' thing. the NFS stuff is a definite improvement in reliability though. and the new tools /are/ backwards compatible. i'd like to see it go in > Alan > regards, --paulj [ps: though i join in the nfs moaning every 2.2pre cycle, i'm still glad to see that it's difficult to slip big patches past you.] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre1
On 1 Sep 2000, Matthias Andree wrote: > Does including knfsd v3 break v2? Is not NFS v3 a compile-time option? I > would not object if it was tagged "EXPERIMENTAL". it is. asui the NFS patches are bugfixes/improvements on the existing stock V2 knfsd, and the feature add v3 is pretty much independent of v2 - and indeed marked experimental. (v3 works fine for me with IRIX 6.2, server/client in both directions). --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] add PPP filtering
Linus,
The patch below adds the ability to filter packets going through a PPP
interface. This allows users to specify that certain types of packets
are not to count as activity, i.e. they don't reset the idle timer or
bring up a demand-dialled link. This is something I have been getting
a lot of requests for.
It also allows users to specify that certain types of packets are to
be dropped - this isn't a substitute for the netfilter stuff of
course, but it comes virtually for free and it can sometimes be
useful.
(Users will need to use ppp-2.4.0 and compile pppd with the line in
pppd/Makefile.linux that says "FILTER=y" uncommented.)
I hope this can go into 2.4. It is a relatively small and
self-contained set of changes. The only change to things outside the
PPP generic module is a small change to make sure that sk_chk_filter
is exported from the socket filtering code. There is also a small
change where I have removed an unnecessary #include from
ppp_channel.h.
The files affected are:
Documentation/Configure.help
drivers/net/ppp_generic.c
include/linux/filter.h
include/linux/if_ppp.h
include/linux/ppp_channel.h
net/netsyms.c
Regards,
Paul.
diff -urN linux/Documentation/Configure.help pmac/Documentation/Configure.help
--- linux/Documentation/Configure.help Sat Sep 2 15:08:58 2000
+++ pmac/Documentation/Configure.help Sat Sep 2 14:58:22 2000
@@ -1748,6 +1748,10 @@
certain types of data to get through the socket. Linux Socket
Filtering works on all socket types except TCP for now. See the text
file Documentation/networking/filter.txt for more information.
+
+ You need to say Y here if you want to use PPP packet filtering
+ (see the CONFIG_PPP_FILTER option below).
+
If unsure, say N.
Network packet filtering
@@ -6719,6 +6723,17 @@
This has to be supported at the other end as well and you need a
version of the pppd daemon which understands the multilink protocol.
+
+ If unsure, say N.
+
+PPP filtering (EXPERIMENTAL)
+CONFIG_PPP_FILTER
+ Say Y here if you want to be able to filter the packets passing over
+ PPP interfaces. This allows you to control which packets count as
+ activity (i.e. which packets will reset the idle timer or bring up
+ a demand-dialled link) and which packets are to be dropped entirely.
+ You need to say Y here if you wish to use the pass-filter and
+ active-filter options to pppd.
If unsure, say N.
diff -urN linux/drivers/net/ppp_generic.c pmac/drivers/net/ppp_generic.c
--- linux/drivers/net/ppp_generic.c Fri Jul 14 14:41:43 2000
+++ pmac/drivers/net/ppp_generic.c Sat Sep 2 15:14:02 2000
@@ -19,7 +19,7 @@
* PPP driver, written by Michael Callahan and Al Longyear, and
* subsequently hacked by Paul Mackerras.
*
- * ==FILEVERSION 2417==
+ * ==FILEVERSION 2902==
*/
#include
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -121,6 +122,10 @@
struct sk_buff_head mrq;/* MP: receive reconstruction queue */
#endif /* CONFIG_PPP_MULTILINK */
struct net_device_stats stats; /* statistics */
+#ifdef CONFIG_PPP_FILTER
+ struct sock_fprog pass_filter; /* filter for packets to pass */
+ struct sock_fprog active_filter;/* filter for pkts to reset idle */
+#endif /* CONFIG_PPP_FILTER */
};
/*
@@ -621,6 +626,43 @@
err = 0;
break;
+#ifdef CONFIG_PPP_FILTER
+ case PPPIOCSPASS:
+ case PPPIOCSACTIVE:
+ {
+ struct sock_fprog uprog, *filtp;
+ struct sock_filter *code = NULL;
+ int len;
+
+ if (copy_from_user(&uprog, (void *) arg, sizeof(uprog)))
+ break;
+ if (uprog.len > 0) {
+ err = -ENOMEM;
+ len = uprog.len * sizeof(struct sock_filter);
+ code = kmalloc(len, GFP_KERNEL);
+ if (code == 0)
+ break;
+ err = -EFAULT;
+ if (copy_from_user(code, uprog.filter, len))
+ break;
+ err = sk_chk_filter(code, uprog.len);
+ if (err) {
+ kfree(code);
+ break;
+ }
+ }
+ filtp = (cmd == PPPIOCSPASS)? &ppp->pass_filter: &ppp->active_filter;
+ ppp_lock(ppp);
+ if (filtp->filter)
+ kfree(filtp->filter);
+ filtp->filter = code;
+ filtp->len = uprog.len;
+ ppp_unlock(ppp);
+ err = 0;
+ break;
+ }
+#endif /* CONFIG_PPP_FILTER */
+
#ifdef CONFIG_PPP_MULTILINK
case PPPIOCSMRRU:
if (get_user(val, (int *) arg))
@@ -892,6 +934,33 @@
int len;
unsigned char *cp;
+
[PATCH] fix ISA dependencies in pcmcia stuff
Linus,
The patch below adds #ifdef CONFIG_ISA to a couple of places in the
pcmcia drivers. This patch allows me to use the cardbus slot on my
Apple powerbook under linux-2.4.0-test8-pre1.
Regards,
Paul.
diff -urN linux/drivers/pcmcia/cardbus.c bk/drivers/pcmcia/cardbus.c
--- linux/drivers/pcmcia/cardbus.c Wed May 3 18:45:18 2000
+++ bk/drivers/pcmcia/cardbus.c Tue Aug 22 09:45:16 2000
@@ -234,6 +234,7 @@
static int cb_assign_irq(u32 mask)
{
+#ifdef CONFIG_ISA
int irq, try;
for (try = 0; try < 2; try++) {
@@ -244,6 +245,7 @@
}
}
}
+#endif
return 0;
}
@@ -369,7 +371,9 @@
void cb_release(socket_info_t * s)
{
+#ifdef CONFIG_ISA
cb_config_t *c = s->cb_config;
+#endif
DEBUG(0, "cs: cb_release(bus %d)\n", s->cap.cb_dev->subordinate->number);
diff -urN linux/drivers/pcmcia/cs.c bk/drivers/pcmcia/cs.c
--- linux/drivers/pcmcia/cs.c Thu Aug 24 17:52:07 2000
+++ bk/drivers/pcmcia/cs.c Fri Aug 25 08:34:48 2000
@@ -1815,8 +1815,11 @@
{
socket_info_t *s;
config_t *c;
-int try, ret = 0, irq = 0;
+int ret = 0, irq = 0;
+#ifdef CONFIG_ISA
+int try;
u_int mask;
+#endif /* CONFIG_ISA */
if (CHECK_HANDLE(handle))
return CS_BAD_HANDLE;
diff -urN linux/drivers/pcmcia/yenta.c bk/drivers/pcmcia/yenta.c
--- linux/drivers/pcmcia/yenta.cThu Aug 10 14:06:49 2000
+++ bk/drivers/pcmcia/yenta.c Tue Aug 22 09:45:16 2000
@@ -482,6 +482,7 @@
static unsigned int yenta_probe_irq(pci_socket_t *socket, u32 isa_irq_mask)
{
+#ifdef CONFIG_ISA
int i;
unsigned long val;
u16 bridge_ctrl;
@@ -519,6 +520,9 @@
config_writew(socket, CB_BRIDGE_CONTROL, bridge_ctrl);
return mask;
+#else
+ return 0;
+#endif /* CONFIG_ISA */
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre2 fs corruption?
On Sun, 3 Sep 2000, Thomas Molina wrote: > Odd. I started seeing mailbox corruption the day before the first post > showed up here. Since it was only one list (BUGTRAQ) and I'm still at weird. currently my pine crashes on me when i close my bugtraq folder. however, i don't think i have fs corruption. (the bugtraq folder is on nfs on a 2.2 server). Perhaps rather than fs corruption, your problem (and mine) is that someone sent a bogey message to bugtraq? regards, -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: Imbalance of power corrupts and monopoly of power corrupts absolutely. -- Genji - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre4: innd fixed?
On Mon, 4 Sep 2000, Linus Torvalds wrote: > The mailbox corruption thread is at least partly due to a pine bug that is > triggered by a bugtraq posting. > confirmed: it is due to multi-line X-Keyword headers (as contained in a recent posting to bugtraq). The bug is in wu c-client, used by pine and imap. so mailboxes served by wu imap might be corrupt too even if accessed from non-pine client. > The truncate issue is unrelated to that, but may certainly show up on > mailboxes too. > > Linus > --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test8-pre2 fs corruption?
On Mon, 4 Sep 2000, Matthew Kirkwood wrote: > Someone has sent a dodgy message to bugtraq. Delete > the mailbox or open it in an editor and look for the > header line that's a lot longer than the others. > that wasn't enough for me. i ended up deleting most of the emails to bugtraq from sep 1 -> sep 4, before pine finally stopped crashing. > (Yes, I'm aware that not all of these reports are from > this, but much of it is.) > > Matthew. > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2 - BSD/OS 4.1 ARP incompatibility
On Tue, 5 Sep 2000, David Luyer wrote: > So if I want it to work I most likely need to make the ARP request ignore > the higher level bindings of the socket. > or just set a route pointing net d.e.f to ethX. > David. > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Availability of kdb
On Wed, 6 Sep 2000, Jeff V. Merkey wrote: > How do you tell a customer who is giving you money to "be careful" when > their system crashes and the field service rep hasn't a clue as to > what's wrong? I've been supporting computer customers for over 20 > years, and this is not an answer that will give them warm and fuzzy > feelings about using your solution if you have no way of solving > problems quickly. so you add kdb to the kernel you ship to customers, teach your reps how to use it.. and hey presto. linus et al are happy cause the standard kernel is pure. you're happy cause your field reps in the event of a crash can tell you "this exact bit here was fubar'ed." whereupon you may apply the Ingo/Al/Linus/David patented MKDB method. regards, -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: panic: can't find / - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-PnP SB AWE32 misbehaving in test7 or newer
> Here's your report. :)
Gerard,
Thanks for the report. I had the patch you mentioned go in
specifically so I could test this feature on all kinds of hardware. The
attached patch fixes two problems. The first was I didn't test for
invalid combinations of module parameters, i.e. using multiple=1 and
isapnp=0 at the same time. The second was if multiple=1 and the driver
finds no ISAPnP cards it would still loop and crash. The second problem
seems to be the one you experienced. The attached patch should fix both
problems.
Please let me know if the attached patch fixes your problem.
Patch made against 2.4.0-test8.
> I've noted one or two other posts to the list with the same / similar
> trouble.
I must have missed them :(
> Gerard Sharp
> Two Penguins on 2.4.0-test6
Paul Laufer
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple && isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
Re: Availability of kdb
arrgghh jeff... On Sun, 10 Sep 2000, Jeff V. Merkey wrote: > One of the principal architects at Compaq called me Friday after > reading Linus' email about not caring about commercial or support > issues for commercialization of Linux on this topic-- his right yes it his right. he cares about the 'goodness' of the kernel. The commercial and support issues he doesn't care about - that's the domain of redhat/suse/compaq/etc../etc... and timpanogas (if you so choose). if you need debugger -> add it to your local tree/ship with a debugger to your customers. > contrary to his development philosophy, so it's probably a > complete waste of my time. > linux kernel hackers do the worrying about 'goodness' but there is *nothing* that stops commerce adding tweaks to help with support issues! (RedHat/SuSE/etc kernels are heavily patched and tweaked!) > Jeff. -- Paul Jakma [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: C'est magnifique, mais ce n'est pas l'Informatique. -- Bosquet [on seeing the IBM 4341] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, 10 Sep 2000, Albert D. Cahalan wrote: > escape Linux 2.2.xx NFS. This is kind of serious, you know? yep. it is serious. we've been begging for knfsd to be updated to the most /current/ code for quite a while a now. I searched the archives and i found a post of mine asking alan to consider an NFS patch sync for 2.2.something - over a year ago. standard linux NFS is dreadful and unstable, and that's just between linux machines. other unixen as clients? don't even try. --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Jeff Garzik wrote: > I hear that the new NFS patch is "better and more stable" etc. but no > details. hard to give details as i havn't used unpatched linux 2.2 nfs in a very long time. best evidence from me is anecdotal: linux 2.4 / 2.2 nfs patches works perfectly for me (linux server, linux/irix clients, V2 and V3), and Trond et al are very responsive if there's problem. (eg silly delete handling bit me a couple of weeks ago, and Trond redid it and had a patch for me within a week or so of diagnosing the problem.). What I remember from using unpatched linux nfs is that it was /awful/ compared to the other unixen i used, most notably in the stability dept. As i remember it a standard linux NFS server never had much of an uptime because of NFS. also dreadful performance to non-linux clients. > It seems to me that if you want an NFS problem fixed in 2.2.x, > address that a single problem with a reproducible test and a small, > focused kernel patch sent to Alan. > there is a patch (well a couple -> server side and client side). The problem is it is never integrated, so now after more than a year of development in NFS the difference between linux nfs and /current/ NFS is bound to be huge. > Whatever Alan's reasons for not including "the 2.2.x NFS patch", I > serious doubt among those reasons is "keep NFS dreadful and unstable." > ;-) unless alan is being paid off by the commercial *nix vendors looking to sell NFS server - no of course not. :) > Maybe it breaks backwards compatibility... not with current nfs-utils. And even if it did: show me anyone who uses standard NFS for anything half-serious that isn't using the patches. (either they're patching themselves or their vendor has included the patch). > so then, someone should pick up the ball and break up the NFS > patch into acceptable, useful, tested chunks. Avoid the stuff > that breaks backwards compatibility, backward compat with what? we're now in the situation that the biggest problem is that so vendors are using different revisions of the nfs problems. none that i know of ship stock linux nfs. even worse: we also have the situation that sometimes people submit small patches against stock linux NFS to fix small problems that are either fixed in the nfs patch or simply were never present in the nfs patches. > but submit the other fixes to > Alan, describing in detail each problem fixed by each patch. > that'd be worth discussing on the nfs list... good idea. > Jeff --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Mon, 11 Sep 2000, Alan Cox wrote: > Shrug. So you want me to make it worse by shipping unproven code in a way > I can't test it ? > the code is in 2.4 and has been tested there though. the patches are a backport of the 2.4 code. --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Alan Cox wrote: > They exist in the same way. You update stuff in controlled careful > steps and you change troublesome drivers very early in a patch > release - eg never touching tulip except early on > true. as i said before i'm glad we have such a 'tight' stable kernel maintainer. :) the problem is, NFS updates /never/ make it in - well once, but even then not the complete NFSv2 update. as for tulip, i know what you mean. however, i think in this case you'd be very hard pressed to find anyone for whom the patches are anything but a vast improvement. anyway... i've gone hoarse now. better stop. :) regards, Paul Jakma - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Alan Cox wrote:
> > ..so it should be at least as well tested as the USB backport in 2.2.18preX,
> > if not more so? Or so is implied. :)
>
> This is the big clue most people are missing
>
> 2.2.17- USB devices do not work
> 2.2.18- USB=n no kernel change USB devices still do not work
> USB=m USB works for most people
>
> USB cant make things any worse than now because you can compile it out.
>
I see where you are coming from, but the {"stock 2.4","2.2 patch"} NFS
code is well tested, lots of bug fixes for NFSv2 and the 'new' code ->
NFSv3 client/server is a compile yes/no option, just like the USB
backport.
2.2 without patches - NFS has performance/reliability problems
2.2 with patches- NFSv2 provided with lots of bugfixes
NFSv3 is compile time optional
I have not heard of anyone that prefers stock 2.2 NFS over
patched/2.4. Anecdotal evidence[1] suggests:
- stock 2.2 has 'issues' with NFS, serving in particular. Bad enough
that linux users would consider switching to another *nix for NFS
serving.
- 2.2 + NFS patches does not have issues (or very few), and would even
appear to work quite well, definitely for NFSv2 and seemingly for
the optional v3[2]. Certainly you need the patches for
interoperability.
- all the NFS developers are working the 2.4 code and backporting to
2.2. So issues wrt to the current 2.2 NFS codebase will not get
fixed. Issues wrt to the 2.4 backport do get fixed.
So the anecdotal evidence suggests we don't have anything to lose but
a not very good NFS server, and everything to gain.
What are the issues with updating NFS code that do not exist with
other drivers, filesystems, etc... in 2.2 for which updates are
accepted?
what is there to lose?
--paulj
[1]. as gathered from posts to this thread, to the nfs sourceforge
lists and my experience of stock NFS as of over a year ago and the NFS
patches since then.
[2]. linux v3 works flawlessly against IRIX 6.2 + ONC3 updates, both
as client and server, for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, 12 Sep 2000, Horst von Brand wrote:
> Better asK: What can _we_ do to assure Alan that NFS is up to snuff?
even if it does suck - so what? it can't possibly suck as much as
current stock NFS. :) but the general view is that 2.2 with patches
is quite useable for NFS serving and as client.
> How can we help along?
the NFS patches (which are a backport of stock 2.4, which descended
from the original 2.2 NFS patches) are now too large and too
different from stock 2.2 to realistically be split up into small
little "this fixes this exact problem". The code is now so far ahead
of stock 2.2 that it is an effective rewrite (and with new, but
optional, NFSv3 client and server and NFS client over TCP code added
on).
alan seems to {want,prefer} small incremental/'obvious fix' patches.
but that isn't practically possible anymore. It would mean the NFS
guys would effectively have to redo the entire development cycle of
code they have written over the last year.
In lieu of a technical argument such as small patches, the only other
arguments are those based on the experiences of people who have tried
to get linux to work reliably as an NFS server and even client. I've
tried to cover those in a previous email, see:
Message-ID: <[EMAIL PROTECTED]>
So it is now at the stage where we either:
1. bite the bullet and sync stock nfs with nfs.sourceforge.net
or
2. accept that stock 2.2 will never have decent NFS server
functionality, and wait for 2.4 to get stable.
we await 2.219pre1 with much curiosity. :)
regards,
--
Paul Jakma [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Where you stand depends on where you sit.
-- Rufus Miles, HEW
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PowerPC Linux for AS/400 & RS/6000 Hardware
Dwayne Grant McConnell ([EMAIL PROTECTED]) writes: > Cort Dougan recently announced he was no longer going to be maintaining > the PowerPC Linux tree. I don't think this is actually correct; I believe what Cort said is that he is no longer maintaining the http://www.ppc.linux.org/ web site. I don't think he meant that he was no longer maintaining Linux for PowerPC. He is away at the moment though. > > LINUX FOR POWERPC AS/400 & RS/6000 > > P: Dwayne Grant McConnell > > M: [EMAIL PROTECTED] > > W: http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc > > L: [EMAIL PROTECTED] > > S: Maintained > > > > LINUX FOR POWERPC AS/400 & RS/6000 > > P: Tom Gall > > M: [EMAIL PROTECTED] > > W: http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc > > L: [EMAIL PROTECTED] > > S: Maintained Suggestion: do it like this: LINUX FOR POWERPC AS/400 & RS/6000 P: Dwayne Grant McConnell M: [EMAIL PROTECTED] P: Tom Gall M: [EMAIL PROTECTED] W: http://oss.software.ibm.com/developerworks/opensource/linux/projects/ppc L: [EMAIL PROTECTED] S: Maintained Regards, Paul. -- Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc. +61 2 6262 8990 tel, +61 2 6262 8991 fax [EMAIL PROTECTED], http://www.linuxcare.com.au/ Linuxcare. Support for the revolution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: sb driver oops in 2.4.0-test8 [BUG found]
Yes, its a bug! My fault. I already sent Linus a patch. It is not
test9-pre1. I have attached it here for you and others on lkml. Please
let me know how it works for you. Patch applies to test7 through test8,
and test9-pre1.
Thanks for your time,
Paul Laufer
On Thu, Sep 14, 2000 at 12:10:36AM -0700 or thereabouts, Joachim Achtzehnter wrote:
> Here is some more info about this problem:
>
> The trouble is caused by the driver's attempt to find multiple
> soundblaster cards. Specifying multiple=0 as a module option for sb fixes
> the problem. Note, however, this quote from the Documentation/Soundblaster
> file:
>
> multiple=0Set to disable detection of multiple Soundblaster cards.
> Consider it a bug if this option is needed, and send in a
> report.
>
> So, this is a bug then!
>
> The function init_sb in drivers/sound/sb_card.c contains a detection loop
> from card=0..SB_CARDS_MAX. This doesn't work, however, because the
> second time around it uses the same module parameters (DMA/IRQ/IO) and
> hence attempts to detect the exact same card instance. The result is not
> only that no second card is found, which is ok in my case, but the
> originally detected card is screwed up as well.
>
> I'm not sufficiently familiar with the driver to know what it should
> do. Could it be that once it can't find a card via isapnp it should bail
> out from this loop?
>
> Joachim
>
> --
> work: [EMAIL PROTECTED] (http://www.realtimeint.com)
> private: [EMAIL PROTECTED] (http://www.kraut.bc.ca)
--- linux-virgin/drivers/sound/sb_card.cSat Sep 9 15:06:13 2000
+++ linux/drivers/sound/sb_card.c Sat Sep 9 15:07:16 2000
@@ -647,7 +647,7 @@
static int __init init_sb(void)
{
- int card, max = multiple ? SB_CARDS_MAX : 1;
+ int card, max = (multiple && isapnp) ? SB_CARDS_MAX : 1;
printk(KERN_INFO "Soundblaster audio driver Copyright (C) by Hannu Savolainen
1993-1996\n");
@@ -660,6 +660,7 @@
if(!sb_cards_num) {
printk(KERN_NOTICE "sb: No ISAPnP cards found, trying
standard ones...\n");
isapnp = 0;
+ max = 1;
} else
break;
}
pcmcia fixes for apple powerbook
David,
The patch below fixes some problems I found in trying to use the
in-kernel pcmcia/cardbus support in 2.4.0-test8 on my 1999 G3
powerbook, which has a TI 1211 cardbus controller.
The first part of the patch fixes a simple endianness problem in cs.c.
Following that is a small change that removes a compile warning when
CONFIG_ISA is not set (as in my case). The change to ti113x.h adds a
special open routine for the TI1211; in my case I need to set the
multifunction pin routing register (config offset 0x8c) to 2 in order
to route the INTA signal out the MFUNC0 pin, and the firmware doesn't
do this automatically. Finally I have added #ifdef CONFIG_ISA in a
couple of places in yenta.c to make sure we don't try to use ISA
interrupt routing when we don't have an ISA bus.
Assuming this patch looks OK to you, could you send it to Linus?
Thanks,
Paul.
diff -urN linux/drivers/pcmcia/cs.c linuxppc_2_3/drivers/pcmcia/cs.c
--- linux/drivers/pcmcia/cs.c Sat Sep 9 19:00:23 2000
+++ linuxppc_2_3/drivers/pcmcia/cs.cSat Sep 16 11:37:29 2000
@@ -1629,6 +1629,7 @@
config_req_t *req)
{
int i;
+u_char b;
u_int base;
socket_info_t *s;
config_t *c;
@@ -1721,14 +1722,14 @@
write_cis_mem(s, 1, (base + CISREG_ESR)>>1, 1, &c->ExtStatus);
}
if (req->Present & PRESENT_IOBASE_0) {
- i = c->io.BasePort1 & 0xff;
- write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &i);
- i = (c->io.BasePort1 >> 8) & 0xff;
- write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &i);
+ b = c->io.BasePort1 & 0xff;
+ write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &b);
+ b = (c->io.BasePort1 >> 8) & 0xff;
+ write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &b);
}
if (req->Present & PRESENT_IOSIZE) {
- i = c->io.NumPorts1 + c->io.NumPorts2 - 1;
- write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &i);
+ b = c->io.NumPorts1 + c->io.NumPorts2 - 1;
+ write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &b);
}
/* Configure I/O windows */
@@ -1835,8 +1836,7 @@
{
socket_info_t *s;
config_t *c;
-int try, ret = 0, irq = 0;
-u_int mask;
+int ret = 0, irq = 0;
if (CHECK_HANDLE(handle))
return CS_BAD_HANDLE;
@@ -1857,6 +1857,7 @@
/* If the interrupt is already assigned, it must match */
irq = s->irq.AssignedIRQ;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+ u_int mask;
mask = req->IRQInfo2 & s->cap.irq_mask;
ret = ((mask >> irq) & 1) ? 0 : CS_BAD_ARGS;
} else
@@ -1864,6 +1865,7 @@
} else {
ret = CS_IN_USE;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+ u_int mask, try;
mask = req->IRQInfo2 & s->cap.irq_mask;
for (try = 0; try < 2; try++) {
for (irq = 0; irq < 32; irq++)
diff -urN linux/drivers/pcmcia/ti113x.h linuxppc_2_3/drivers/pcmcia/ti113x.h
--- linux/drivers/pcmcia/ti113x.h Thu May 25 12:53:52 2000
+++ linuxppc_2_3/drivers/pcmcia/ti113x.hSat Sep 16 11:37:29 2000
@@ -272,6 +272,36 @@
yenta_proc_setup
};
+static int ti1211_open(pci_socket_t *socket)
+{
+#ifdef CONFIG_PPC
+ /*
+* On Powerbooks with the TI1211 cardbus chip, we have to set the
+* multifunction pin routing register to route the PCI INTA to the
+* MFUNC0 pin.
+*/
+ config_writel(socket, TI122X_IRQMUX, 2);
+#endif /* CONFIG_PPC */
+
+ ti_open(socket);
+ return 0;
+}
+
+static struct pci_socket_ops ti1211_ops = {
+ ti1211_open,
+ yenta_close,
+ ti_init,
+ yenta_suspend,
+ yenta_get_status,
+ yenta_get_socket,
+ yenta_set_socket,
+ yenta_get_io_map,
+ yenta_set_io_map,
+ yenta_get_mem_map,
+ yenta_set_mem_map,
+ yenta_proc_setup
+};
+
#endif /* CONFIG_CARDBUS */
#endif /* _LINUX_TI113X_H */
diff -urN linux/drivers/pcmcia/yenta.c linuxppc_2_3/drivers/pcmcia/yenta.c
--- linux/drivers/pcmcia/yenta.cSat Sep 9 19:00:23 2000
+++ linuxppc_2_3/drivers/pcmcia/yenta.c Sat Sep 16 11:37:29 2000
@@ -240,6 +240,7 @@
u8 intr;
bridge |= (state->flags & SS_RESET) ? CB_BRIDGE_CRST : 0;
+#ifdef CONFIG_ISA
/* ISA interrupt control? */
intr = exca_readb(socket, I365_INTCTL);
intr = (intr & ~0xf);
@@ -248,10 +249,13 @@
bridge |= CB_BRIDGE_INTR;
}
exca_writeb(socket, I365_INTCTL, intr);
+#endif /* CONFIG_ISA */
} else {
u8 reg;
+#ifdef CONFIG_ISA
bridge |= CB_BRIDGE_INTR;
+#endif /* CONFIG_ISA */
reg = e
pcmcia fixes for apple powerbook
David,
The patch below fixes some problems I found in trying to use the
in-kernel pcmcia/cardbus support in 2.4.0-test9-pre1 on my 1999 G3
powerbook, which has a TI 1211 cardbus controller.
The first part of the patch fixes a simple endianness problem in cs.c.
Following that is a small change that removes a compile warning when
CONFIG_ISA is not set (as in my case). The change to ti113x.h adds a
special open routine for the TI1211; in my case I need to set the
multifunction pin routing register (config offset 0x8c) to 2 in order
to route the INTA signal out the MFUNC0 pin, and the firmware doesn't
do this automatically. Finally I have added #ifdef CONFIG_ISA in a
couple of places in yenta.c to make sure we don't try to use ISA
interrupt routing when we don't have an ISA bus.
I'm also seeing some contact bounce problems when cards are inserted,
although test9-pre1 is slightly better than test8 in this respect. If
I kill cardmgr, install the card, and restart cardmgr, it comes up
just fine.
Assuming this patch looks OK to you, could you send it to Linus?
Thanks,
Paul.
diff -urN linux/drivers/pcmcia/cs.c pmac/drivers/pcmcia/cs.c
--- linux/drivers/pcmcia/cs.c Sat Sep 16 16:25:57 2000
+++ pmac/drivers/pcmcia/cs.cSat Sep 16 16:54:07 2000
@@ -1634,6 +1634,7 @@
config_req_t *req)
{
int i;
+u_char b;
u_int base;
socket_info_t *s;
config_t *c;
@@ -1726,14 +1727,14 @@
write_cis_mem(s, 1, (base + CISREG_ESR)>>1, 1, &c->ExtStatus);
}
if (req->Present & PRESENT_IOBASE_0) {
- i = c->io.BasePort1 & 0xff;
- write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &i);
- i = (c->io.BasePort1 >> 8) & 0xff;
- write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &i);
+ b = c->io.BasePort1 & 0xff;
+ write_cis_mem(s, 1, (base + CISREG_IOBASE_0)>>1, 1, &b);
+ b = (c->io.BasePort1 >> 8) & 0xff;
+ write_cis_mem(s, 1, (base + CISREG_IOBASE_1)>>1, 1, &b);
}
if (req->Present & PRESENT_IOSIZE) {
- i = c->io.NumPorts1 + c->io.NumPorts2 - 1;
- write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &i);
+ b = c->io.NumPorts1 + c->io.NumPorts2 - 1;
+ write_cis_mem(s, 1, (base + CISREG_IOSIZE)>>1, 1, &b);
}
/* Configure I/O windows */
@@ -1840,8 +1841,7 @@
{
socket_info_t *s;
config_t *c;
-int try, ret = 0, irq = 0;
-u_int mask;
+int ret = 0, irq = 0;
if (CHECK_HANDLE(handle))
return CS_BAD_HANDLE;
@@ -1862,6 +1862,7 @@
/* If the interrupt is already assigned, it must match */
irq = s->irq.AssignedIRQ;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+ u_int mask;
mask = req->IRQInfo2 & s->cap.irq_mask;
ret = ((mask >> irq) & 1) ? 0 : CS_BAD_ARGS;
} else
@@ -1869,6 +1870,7 @@
} else {
ret = CS_IN_USE;
if (req->IRQInfo1 & IRQ_INFO2_VALID) {
+ u_int mask, try;
mask = req->IRQInfo2 & s->cap.irq_mask;
for (try = 0; try < 2; try++) {
for (irq = 0; irq < 32; irq++)
diff -urN linux/drivers/pcmcia/ti113x.h pmac/drivers/pcmcia/ti113x.h
--- linux/drivers/pcmcia/ti113x.h Thu May 25 12:53:52 2000
+++ pmac/drivers/pcmcia/ti113x.hFri Sep 15 23:36:53 2000
@@ -272,6 +272,36 @@
yenta_proc_setup
};
+static int ti1211_open(pci_socket_t *socket)
+{
+#ifdef CONFIG_PPC
+ /*
+* On Powerbooks with the TI1211 cardbus chip, we have to set the
+* multifunction pin routing register to route the PCI INTA to the
+* MFUNC0 pin.
+*/
+ config_writel(socket, TI122X_IRQMUX, 2);
+#endif /* CONFIG_PPC */
+
+ ti_open(socket);
+ return 0;
+}
+
+static struct pci_socket_ops ti1211_ops = {
+ ti1211_open,
+ yenta_close,
+ ti_init,
+ yenta_suspend,
+ yenta_get_status,
+ yenta_get_socket,
+ yenta_set_socket,
+ yenta_get_io_map,
+ yenta_set_io_map,
+ yenta_get_mem_map,
+ yenta_set_mem_map,
+ yenta_proc_setup
+};
+
#endif /* CONFIG_CARDBUS */
#endif /* _LINUX_TI113X_H */
diff -urN linux/drivers/pcmcia/yenta.c pmac/drivers/pcmcia/yenta.c
--- linux/drivers/pcmcia/yenta.cSat Sep 16 16:25:57 2000
+++ pmac/drivers/pcmcia/yenta.c Sat Sep 16 17:13:38 2000
@@ -245,6 +245,7 @@
u8 intr;
bridge |= (state->flags & SS_RESET) ? CB_BRIDGE_CRST : 0;
+#ifdef CONFIG_ISA
/* ISA interrupt control? */
intr = exca_readb(socket, I365_INTCTL);
intr = (intr & ~0xf);
@@ -253,10 +254,13 @@
bridge |= CB_BRIDGE_INTR;
}
exca_writeb(socket, I365
SCSI problem: 2.4.0-test8 through 2.4.0-test9-pre2
Hi, The problem is this: in 2.4.0-test8 someone sent in a patch that removed the #ifdef MODULE, #endif pair from around the module initialization routines in drivers/scsi/sr.c and drivers/scsi/sd.c and changed them from the older style init_module()/cleanup_module() syntax to the newer style module_init(init_function)/module_exit(exit_function) syntax. The result is now when sd.c or sr.c are compiled into the kernel, not as modules, the module-only initialization routines are run at boot time. This results in all my disks being detected twice, so since I have two scsi disks sda is now sda _and_ sdc, and sdb is sdb _and_ sdd. Another side effect is that subsequent loading of any lowlevel scsi modules such as ide-scsi or ppa, for example, will result in a scsi subsystem lockup because the lists have been whacked. Just letting you know in hope it'll get fixed soon. Thanks for your time, Paul Laufer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: relocation truncated to fit: R_386_PC32
Keith Owens wrote:
>
> Sections marked __exit get discarded when the code is linked into the
> kernel, they are kept when the code is a module. But the spin lock
> code is kept (in another section) and relocation from .text.lock back
> to .text.exit fails. Possible fixes:
>
> Use RTC as a module.
> Remove __exit from rtc_exit.
> Compile rtc_exit conditional on not being a module.
> Remove the spin locks.
... or
5) Delete paranoia check altogether.
Thanks,
Paul.
--- drivers/char/rtc.c~ Sun Jul 23 03:39:15 2000
+++ drivers/char/rtc.c Tue Sep 19 11:08:47 2000
@@ -723,17 +723,6 @@
static void __exit rtc_exit (void)
{
- /* interrupts and maybe timer disabled at this point by rtc_release */
- /* FIXME: Maybe??? */
-
- if (rtc_status & RTC_TIMER_ON) {
- spin_lock_irq (&rtc_lock);
- rtc_status &= ~RTC_TIMER_ON;
- del_timer(&rtc_irq_timer);
- spin_unlock_irq (&rtc_lock);
-
- printk(KERN_WARNING "rtc_exit(), and timer still running.\n");
- }
remove_proc_entry ("driver/rtc", NULL);
misc_deregister(&rtc_dev);
__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Removing boot text
We are using Linux as a bootable CD for system configuration. We would like to keep all the information displayed at bootup hidden. The main reason for this is because our users see words such as "error" and "failed" and it bothers them (though there is nothing wrong). Anyone know how other than changing the kernel code? Thanks __ Do You Yahoo!? Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free! http://photos.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.2.x Isdn init function fix
On Thu 28 Sep 2000, Luca Montecchiani wrote:
> Init function for hisax driver cause a kernel hangup if the
> idstring was omitted
Good catch.
> - if (strlen(str)) {
> + if (str) {
I'd make this:
+ if (str && *str) {
to preserve the intention of the original code
(the string mustn't be empty).
> - if (strlen(str)) {
> + if (str) {
ditto
Paul Slootman
--
home: [EMAIL PROTECTED] http://www.wurtel.demon.nl/
work: [EMAIL PROTECTED] http://www.murphy.nl/
debian: [EMAIL PROTECTED] http://www.debian.org/
isdn4linux: [EMAIL PROTECTED] http://www.isdn4linux.de/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH against 2.4.2: TTY hangup on PPP channel corrupts kernel memory
Kevin Buhr writes:
> If there's a hangup in the TTY layer on an async PPP channel,
> do_tty_hangup shuts down the PPP line discipline, and, in ppp_async.c,
> the function ppp_asynctty_close unregisteres the channel. In
> ppp_generic.c, ppp_unregister_channel merrily wakes up the rwait
> queue, then proceeds to destroy the channel, freeing the "struct
> channel" which contains the "struct ppp_file" that contains the
> "wait_queue_head_t rwait". When the waiting process wakes up, it
> removes itself from the wait queue, modifying freed memory.
But the waiting process must have had an instance of /dev/ppp open and
attached to the channel in order to be doing anything with rwait,
within either ppp_file_read or ppp_poll. The process of attaching to
the channel increases its refcnt, meaning that the channel shouldn't
be destroyed until the instance of /dev/ppp is closed and ppp_release
is called.
Note that pppd will not be blocking inside ppp_file_read since it sets
the file descriptor non-blocking. Most of the time pppd would be
inside a select, so rwait would be in use by the poll/select code.
I presume that the generic file descriptor code ensures that the file
release function doesn't get called while any task is inside the read
or write function for that file, or while the file descriptor is in
use in a select or poll. If that assumption is wrong then it would
indeed be possible for the channel to be destroyed while some process
is waiting on rwait. But in any case it shouldn't be a problem in
practice since it would only be pppd that would have the channel open
and pppd is single-threaded, i.e. it couldn't be closing the file
descriptor while it is blocked inside read or select.
So, to put it in other words, this is the sequence (simplified):
fd = open("/dev/ppp", O_RDWR);
ioctl(fd, PPPIOCATTCHAN, &channel_number);
fcntl(fd, F_SETFL, fcntl(fd, F_GETFL) | O_NONBLOCK);
select(...);/* fd_sets including fd */
read(fd, ...);
...
close(fd);
I believe the channel structure is guaranteed to exist from the ioctl
to the close, and all the selects and reads (i.e. all the uses of
rwait) have to happen within that time interval.
> A patch against 2.4.2 follows. I've overloaded the "refcnt" in
> "struct ppp_file" to also keep track of rwaiters. The last refcnt
> user destroys the channel and decreases the module use count. I've
> tested this with printks in all the right places, and it seems to fix
> the problem correctly.
I'm not sure this is the right fix, this sounds to me like the
refcounts are going awry somehow or there is an SMP race that I
haven't considered, and I am concerned that this patch will just cover
over the real problem. Actually, given that you've seen it 4 times in
6 months it's more likely that it is an SMP race IMHO.
In any case I don't think your patch does the right thing with
ppp_poll, because poll_wait doesn't actually wait, it just adds rwait
to a list of things to watch for wakeups. In other words, rwait will
be in use from the time poll_wait is called until the time that the
poll/select logic (in fs/select.c) decides that it's time to return to
the user. So increasing the refcount around just the poll_wait call
won't help much.
Do you have a way to reproduce the problem at will? Have you seen it
happen on a UP box (i.e. could it be an SMP race)? How sure are you
that your patch really fixes the problem?
Regards,
Paul.
--
Paul Mackerras, Open Source Research Fellow, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
[EMAIL PROTECTED], http://www.linuxcare.com.au/
Linuxcare. Putting Open Source to work.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] off-by-1 error in ide-probe (2.4.x)
There is a potentially serious bug in ide-probe.c in which max_sectors
is set to 256 instead of 255. I am surprised that this hasn't bit anyone
else yet. Perhaps because you need a disk that is slow in comparison to
the host in order for the queue to climb up to and then hit the 256, at
which point it then falls over.
For example, with an old 700MB Maxtor on a "fast" 486, VL-bus, PIO,
hdparm -c1 -m8 -u1, I could pretty much on demand generate the following
error by multiple builds, or by the final linking of any big project:
hdc: lost interrupt
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
(Note that nothing in the status is really an error). With the following
patch, everything works as it should & no errors even under high load.
Patch is against 2.4.3pre2.
Paul.
--- drivers/ide/ide-probe.c~Sat Mar 17 16:50:14 2001
+++ drivers/ide/ide-probe.c Sat Mar 17 16:58:33 2001
@@ -1,5 +1,5 @@
/*
- * linux/drivers/ide/ide-probe.c Version 1.06June 9, 2000
+ * linux/drivers/ide/ide-probe.c Version 1.07March 18, 2001
*
* Copyright (C) 1994-1998 Linus Torvalds & authors (see below)
*/
@@ -25,6 +25,8 @@
* allowed for secondary flash card to be detectable
* with new flag : drive->ata_flash : 1;
* Version 1.06stream line request queue and prep for cascade project.
+ * Version 1.07max_sect <= 255; slower disks would get behind and
+ * then fall over when they get to 256.Paul G.
*/
#undef REALLY_SLOW_IO /* most systems can safely undef this */
@@ -772,10 +774,10 @@
for (unit = 0; unit < minors; ++unit) {
*bs++ = BLOCK_SIZE;
#ifdef CONFIG_BLK_DEV_PDC4030
- *max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : 256);
+ *max_sect++ = ((hwif->chipset == ide_pdc4030) ? 127 : 255);
#else
/* IDE can do up to 128K per request. */
- *max_sect++ = 256;
+ *max_sect++ = 255;
#endif
*max_ra++ = MAX_READAHEAD;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] off-by-1 error in ide-probe (2.4.x)
Jens Axboe wrote:
> You don't need a slow disk, it's trivial to provoke 256 sector sized
> request on even the fastest disk available. People hit it all the time,
> just with working drives...
Here is an update on the 255 vs 256 IDE issue. As Jens said, if it
screws up on every 256, then I shouldn't have to try at all to trip
it up - a simple dd should do it (but it doesn't). So I thought I'd
test some more & collect up the details before posting again.
Offending disk:
--
Model=Maxtor 7850 AV, FwRev=OA7X5B57, SerialNo=
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>5Mbs FmtGapReq }
RawCHS=1654/16/63, TrkSize=0, SectSize=0, ECCbytes=11
BuffType=3(DualPortCache), BuffSize=64kB, MaxMultSect=8, MultSect=8
DblWordIO=yes, maxPIO=2(fast), DMA=yes, maxDMA=1(medium)
CurCHS=1654/16/63, CurSects=1667232, LBA=yes, LBAsects=1667232
tDMA={min:150,rec:150}, DMA modes: sword0 sword1 *sword2 *mword0
IORDY=on/off, tPIO={min:180,w/IORDY:150}, PIO modes: mode3
System Details:
--
Installed as primary (and only device) on ide1, which is a VL-bus
PIO card on 40MHz bus, booting with idebus=40, Am5x86-WT (i.e. 486)
in a Gigabyte SiS '471 chipset board. Disk tuned with "-c1 -m8 -u1".
Interface ide0 on same card has 2Gig Maxtor on it, which does not
appear to have problems (easier to show a failure happens than prove a
failure will never happen...) ide0 is not in use during failures, as
root fs is on SCSI.
Failure Cases:
--
My "test" at the moment consists of:
nice -n20 make bootstrap > make.log 2>&1 & tail -f make.log
while also doing a:
while [ 1 ]; do gunzip -vt some-7MB-o-cruft.tar.gz ; sleep 60 ; done
The GCC src & the tarball are on problem disk. The sleep ensures the
gcc build has pushed the tarball out of the 24MB of RAM. This then gives:
hdc: lost interrupt
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
in less than an hour (it varies of course). The one case where I happened
to "see" it fail, the drive LED stayed on (drive quiet, no seeks) until
the timer fired off and printed the message(s). Some times (3 out of 13
failures so far) I have seen the more suspect:
hdc: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
ide1: unexpected interrupt, status=0x58, count=1
hdc: status error: status=0x58 { DriveReady SeekComplete DataRequest }
hdc: drive not ready for command
all with the same timestamp in the syslog. (IRQ timeout followed by
unexpected IRQ ... ??? Hrrm.)
Most times gzip will get invalid data when a failure happens, but on
occasion random cruft has appeared in the GCC source that stops the
build. Forcing a re-read from the disk will return the correct data
in both cases. I haven't seen corrupt writes (at least none I've
detected yet...)
Compiler/Kernel:
I went back and double checked (2.4.3-pre4) breaks on 256 but works
reliably on 255. I have confirmed this for both gcc-2.95.2 and
gcc-2.7.2 (with appropriate workarounds for old gcc bugs) so it
shouldn't be a compiler issue.
More interesting is that I took a bone stock 2.2.18, which still uses
MAX_SECTORS (==128) in ide-probe.c and changed that to 256. This
caused 2.2.18 to fail in exactly the same way under the same test.
The 2.2.18 kernel without this change will complete the whole gcc
build without fail (on a 486-24MB, with gzip eating CPU, this takes
a while...)
Conclusions:
I don't see this problem on any other machines, which includes some
pretty lame hardware (even an early 40MB *stepper motor* based WD IDE
seems to behave OK on 256).
So the 255 (or even the old 128) fixes things vs. 256, but I'd feel
better being 100% sure why. (i.e. is 255 a "fix" or a perturbation that
happens to paper over something else). If time permits, I will try
swapping hda with hdc - that will get the problem disk off of the
possibly noisy IRQ15 - and see what happens then. If it truly is a
one-off buggy disk, then maybe the fix is a large hammer, not a patch.
Ok, I think that is about as detailed as I can get. Ask if I left
something out. Commentary welcome, even an Me too! .
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Serial port latency
> The serial port chip is 16550A, which has a built in fifo. Can this be > the source of my problems ? > > Geir I thought about that. If the number of receive bytes in the RX FIFO is less that the trigger level then a timeout has to occur before getting the next receive data interrupt. The 16550AF data book says that this timeout is 4 characters from when the last byte is received. This is a maximum of 160ms at 300bps (when using 12bit characters: 1 start + 8 data + parity + 2 stop). So this would be smaller at 9600 and could not account for the 500ms delay. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH against 2.4.2: TTY hangup on PPP channel corrupts kernel memory
Kevin Buhr writes: > I didn't realize my specific hang was a peculiarity of the older > attachment style. The channel created by pushing the PPP line I didn't realize you were talking about linux 2.4.0 and pppd 2.3.11. > discipline onto a TTY was connected to a unit with a PPPIOCATTACH > ioctl on the TTY---this didn't really "attach" the channel; it still > had a refcnt of only one. Through the old compatibility interface, it > was possible to call ppp_asynctty_read -> ppp_channel_read -> ppp_read > on the channel's "struct ppp_file" and wait on the channel's "rwait". > If the modem hung up, "do_tty_hangup" would call "ppp_asynctty_close" > (with a reader still in "ppp_asynctty_read") and the "struct channel" > would be freed in "ppp_unregister_channel". That's one of the main reasons why I removed the compatibility stuff. :) > I think your analysis of how things presently are with 2.4.2 and a > modern "pppd" is correct... > > Since the new "pppd" uses an explicit PPPIOCATTCHAN / PPPIOCCONNECT > sequence, the refcnt gets bumped to 2 and stays there while the > channel is attached. So, this specific hang isn't a problem anymore > for "ppp_async.c". It's still a problem with "ppp_synctty.c", though > (when used with "pppd" 2.3.11, say). Is the compatibility stuff in > there slated for removal, too? Yep, and we should take out the stuff in ppp_generic.c that was called by the compatibility stuff in the channels, too. > In particular, the comment above "ppp_asynctty_close" is misleading. > It's true that the TTY layer won't call any further line discipline > entries while the "close" is executing; however, there may be > processes already sleeping in line discipline functions called before > the hangup. For example, "ppp_asynctty_close" could be called while > we sleep in the "get_user" in "ppp_channel_ioctl" (called from > "ppp_asynctty_ioctl"). Therefore, calling "PPPIOCATTACH" on an > unattached PPP-disciplined TTY could, in unlikely circumstances > (argument swapped out), lead to a crash. Yuck. I don't see that we can protect against this without having some sort of lock in the tty structure, though. We can't protect the existence of the channel structure with a lock inside that structure. Ideally the necessary protection would be provided at the tty level. > I assume PPPIOCATTACH (on the TTY) is deprecated in favor of > PPPIOCATTCHAN / PPPIOCCONNECT (on the "/dev/ppp" handle). Can we > eliminate "ppp_channel_ioctl" from "ppp_async.c" entirely, as in the > patch below? We're requiring people to upgrade to "pppd" 2.4.0 > anyway, and it has no need for these calls. This would give me a warm, > fuzzy feeling. Sure, that would be fine. I'll make up a patch and send it to Linus. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 against 2.4.2: TTY hangup on PPP channel corrupts kernel memory
From: "Andrew Morton" <[EMAIL PROTECTED]> > Your analysis is correct. It's a bug. > > Furthermore, n_hdlc_tty_open() (for example) can sleep prior to > incrementing the module refcount, which means the module can be > unloaded while it's running. I cut a patch ages ago which fixes > this one for both ttys and ldiscs. I never got around to sending > it to anyone. > > > Does this mean that all line discipline implementations must use a > > spinlock around critical code in "open", "close", and every other line > > discipline function? It looks like they must, and it looks like most > > don't right now. I have experienced essentially the same problem: A line discipline can be switched while a user mode program is blocked inside of a line discipline call. In my case the call was ioctl() (select) which went through the ldisc (n_hdlc) and was being serviced by (and blocked in) the tty layer. Two processes had the underlying serial device open. One process restored the ldisc to N_TTY, exited, and the script that started the process unloaded the ldisc driver (which had a zero ref count as a result of being switched out). When the select call of the other process tried to return (to the n_hdlc ldisc), the code was already unloaded and an oops occurred. I was not too worried about this because it was caused by a series of wrong (buggy) moves by the user mode processes. But it goes back to the problem of allowing the ldisc to change when there are existing calls blocked in (or through) the ldisc. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Prevent OOM from killing init
On Fri, 23 Mar 2001, Guest section DW wrote: > But yes, I am complaining because Linux by default is unreliable. no, your distribution is unreliable by default. > I strongly prefer a system that is reliable by default, > and I'll leave it to others to run it in an unreliable mode. currently, setting sensible user limits on my machines means i never get a hosed machine due to OOM. These limits are easy to set via pam_limits. (not perfect though, i think its session specific..) granted, if the machine hasn't been setup with user limits, then linux doesn't deal at all well with OOM, so this should be fixed. but it can easily be argued that admin error in not configuring limits is the main cause for OOM. > Andries regards, --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Prevent OOM from killing init
On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote: > About the "use resource limits!". Yes, this is one solution. The > *expensive* solution (admin time, worse resource utilization, etc). traditional user limits have worse resource utilisation? think what kind of utilisation a guaranteed allocation system would have. instead of 128MB, you'd need maybe a GB of RAM and many many GB of swap for most systems. some hopefully non-ranting points: - setting up limits on a RH system takes 1 minute by editing /etc/security/limits.conf. - Rik's current oom killer may not do a good job now, but it's impossible for it to do a /perfect/ job without implementing kernel/esp.c. - with limits set you will have: - /possible/ underutilisation on some workloads. - chance of hitting Rik's OOM killer reduced to almost nothing. no matter how good or bad Rik's killer is, i'd much rather set limits and just about /never/ have it invoked. more beancounting will make limits more useful (eg global?) and maybe dists can start setting up some kind of limits by default at install time based on the RAM installed and whether user selected server/workstation/etc.. install. Then hopefully we can be a little less concerned about how close Rik gets to the impossible task of implementing esp.c. > Szaka --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Prevent OOM from killing init
On Sat, 24 Mar 2001 [EMAIL PROTECTED] wrote: > No, ulimit does not work. (But it helps a little.) no, not perfect, i very much agree. but in daily usage it reduces chance of OOM to close to 0. > No, /proc/sys/vm/overcommit_memory does not work. that's because it disables the very rough resource checking that linux has. it makes OOM even easier to achieve: mm/mmap.c::vm_enough_memory(): /* Sometimes we want to use more memory than we have. */ if (sysctl_overcommit_memory) return 1; it doesn't make linux go into a 'non-overcommit' mode, cause linux does not have the accounting to cover it... solution according to more knowledgable folks than i, sysadmin, is better accounting so that vm_enough_memory can be more accurate rather than developing an all-seeing oom_killer(). > Andries regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: "We are on the verge: Today our program proved Fermat's next-to-last theorem." -- Epigrams in Programming, ACM SIGPLAN Sept. 1982 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] Prevent OOM from killing init
On Sat, 24 Mar 2001, Szabolcs Szakacsits wrote: > Nonsense hodgepodge. See and/or mesaure the impact. I sent numbers in my > former email. You also missed non-overcommit must be _optional_ [i.e. > you wouldn't be forced to use it ;)]. Yes, there are users and > enterprises who require it and would happily pay the 50-100% extra swap > space for the same workload and extra reliability. ok.. the last time OOM came up, the main objection to fully guaranteed vm was the possible huge overhead. if someone knows how to do it without a huge overhead, i'd love to see it and try it out. > At every time you add/delete users, add/delete special apps, etc. no.. pam_limits knows about groups, and you can specify limit for that group, one time. @user ... ... ... > Rik's killer is quite fine at _default_. But there will be always > people who won't like it exactly... so lets try avoid ever needing it. it is a last resort. > default, use the /proc/sys/vm/oom_killer interface"? As I said > before there are also such patch by Chris Swiedler and definitely > not a huge, complex one. uhmm.. where? > And these stupid threads could be forgotten for good and all. :) > Szaka regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: The optimum committee has no members. -- Norman Augustine - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] MM update for PPC
Linus,
The patch below updates the MM code for PowerPC to correspond with the
recent generic MM changes. The patch is against 2.4.3-pre7, and it
affects only arch/ppc/mm/init.c, include/asm-ppc/pgalloc.h, and
include/asm-ppc/semaphore.h.
The changes to semaphore.h are only necessary because the definition
of INIT_MM in sched.h uses __RWSEM_INITIALIZER with the argument of
RW_LOCK_BIAS, meaning an unlocked semaphore. I think RW_LOCK_BIAS is
at the very least a horrible name for something that means an unlocked
semaphore, and in fact it is really a private definition used in the
i386 semaphore code which should never be used in generic code like
this. (But no I don't have a patch to fix this properly at the
moment.)
Paul.
diff -urN linux/arch/ppc/mm/init.c linuxppc_2_4/arch/ppc/mm/init.c
--- linux/arch/ppc/mm/init.cWed Mar 21 15:43:54 2001
+++ linuxppc_2_4/arch/ppc/mm/init.c Thu Mar 22 10:39:23 2001
@@ -110,7 +110,7 @@
#endif
void MMU_init(void);
-static void *MMU_get_page(void);
+void *early_get_page(void);
unsigned long prep_find_end_of_memory(void);
unsigned long pmac_find_end_of_memory(void);
unsigned long apus_find_end_of_memory(void);
@@ -125,7 +125,7 @@
unsigned long m8260_find_end_of_memory(void);
#endif /* CONFIG_8260 */
static void mapin_ram(void);
-void map_page(unsigned long va, unsigned long pa, int flags);
+int map_page(unsigned long va, unsigned long pa, int flags);
void set_phys_avail(unsigned long total_ram);
extern void die_if_kernel(char *,struct pt_regs *,long);
@@ -206,41 +206,20 @@
pmd_val(*pmd) = (unsigned long) BAD_PAGETABLE;
}
-pte_t *get_pte_slow(pmd_t *pmd, unsigned long offset)
-{
-pte_t *pte;
-
-if (pmd_none(*pmd)) {
- if (!mem_init_done)
- pte = (pte_t *) MMU_get_page();
- else if ((pte = (pte_t *) __get_free_page(GFP_KERNEL)))
- clear_page(pte);
-if (pte) {
-pmd_val(*pmd) = (unsigned long)pte;
-return pte + offset;
-}
- pmd_val(*pmd) = (unsigned long)BAD_PAGETABLE;
-return NULL;
-}
-if (pmd_bad(*pmd)) {
-__bad_pte(pmd);
-return NULL;
-}
-return (pte_t *) pmd_page(*pmd) + offset;
-}
-
int do_check_pgt_cache(int low, int high)
{
int freed = 0;
- if(pgtable_cache_size > high) {
+ if (pgtable_cache_size > high) {
do {
- if(pgd_quicklist)
- free_pgd_slow(get_pgd_fast()), freed++;
- if(pmd_quicklist)
- free_pmd_slow(get_pmd_fast()), freed++;
- if(pte_quicklist)
- free_pte_slow(get_pte_fast()), freed++;
- } while(pgtable_cache_size > low);
+if (pgd_quicklist) {
+ free_pgd_slow(get_pgd_fast());
+ freed++;
+ }
+ if (pte_quicklist) {
+ pte_free_slow(pte_alloc_one_fast());
+ freed++;
+ }
+ } while (pgtable_cache_size > low);
}
return freed;
}
@@ -383,6 +362,7 @@
__ioremap(unsigned long addr, unsigned long size, unsigned long flags)
{
unsigned long p, v, i;
+ int err;
/*
* Choose an address to map it to.
@@ -453,10 +433,20 @@
flags |= _PAGE_GUARDED;
/*
-* Is it a candidate for a BAT mapping?
+* Should check if it is a candidate for a BAT mapping
*/
- for (i = 0; i < size; i += PAGE_SIZE)
- map_page(v+i, p+i, flags);
+
+ spin_lock(&init_mm.page_table_lock);
+ err = 0;
+ for (i = 0; i < size && err == 0; i += PAGE_SIZE)
+ err = map_page(v+i, p+i, flags);
+ spin_unlock(&init_mm.page_table_lock);
+ if (err) {
+ if (mem_init_done)
+ vfree((void *)v);
+ return NULL;
+ }
+
out:
return (void *) (v + (addr & ~PAGE_MASK));
}
@@ -492,7 +482,7 @@
return (pte_val(*pg) & PAGE_MASK) | (addr & ~PAGE_MASK);
}
-void
+int
map_page(unsigned long va, unsigned long pa, int flags)
{
pmd_t *pd;
@@ -501,10 +491,13 @@
/* Use upper 10 bits of VA to index the first level map */
pd = pmd_offset(pgd_offset_k(va), va);
/* Use middle 10 bits of VA to index the second-level map */
- pg = pte_alloc(pd, va);
+ pg = pte_alloc(&init_mm, pd, va);
+ if (pg == 0)
+ return -ENOMEM;
set_pte(pg, mk_pte_phys(pa & PAGE_MASK, __pgprot(flags)));
if (mem_init_done)
flush_hash_page(0, va);
+ return 0;
}
#ifndef
[PATCH] mdacon needs to use __setup()
The kernel command line setup function for MDA console support is
currently dangling in outer space and not called (and hence non
functional). There was also a warning about a non used function
whose callers were half /* */ 'ed out so I cleaned that up as well.
Patch should apply to any recent 2.4.x kernel.
Paul.
--- drivers/video/mdacon.c~ Wed Feb 14 02:41:44 2001
+++ drivers/video/mdacon.c Mon Mar 12 19:37:21 2001
@@ -21,6 +21,9 @@
* This file is subject to the terms and conditions of the GNU General Public
* License. See the file COPYING in the main directory of this archive for
* more details.
+ *
+ * Changelog:
+ * Paul G. (03/2001) Fix mdacon= boot prompt to use __setup().
*/
#include
@@ -129,6 +132,7 @@
spin_unlock_irqrestore(&mda_lock, flags);
}
+#ifdef TEST_MDA_B
static int test_mda_b(unsigned char val, unsigned char reg)
{
unsigned long flags;
@@ -143,6 +147,7 @@
spin_unlock_irqrestore(&mda_lock, flags);
return val;
}
+#endif
static inline void mda_set_origin(unsigned int location)
{
@@ -182,20 +187,27 @@
#ifndef MODULE
-void __init mdacon_setup(char *str, int *ints)
+static int __init mdacon_setup(char *str)
{
/* command line format: mdacon=, */
+ int ints[3];
+
+ str = get_options(str, ARRAY_SIZE(ints), ints);
+
if (ints[0] < 2)
- return;
+ return 0;
if (ints[1] < 1 || ints[1] > MAX_NR_CONSOLES ||
ints[2] < 1 || ints[2] > MAX_NR_CONSOLES)
- return;
+ return 0;
- mda_first_vc = ints[1]-1;
- mda_last_vc = ints[2]-1;
+ mda_first_vc = ints[1];
+ mda_last_vc = ints[2];
+ return 1;
}
+
+__setup("mdacon=", mdacon_setup);
#endif
static int __init mda_detect(void)
@@ -237,17 +249,19 @@
* memory location, so now we do an I/O port test.
*/
+#ifdef TEST_MDA_B
/* Edward: These two mess `tests' mess up my cursor on bootup */
/* cursor low register */
- /* if (! test_mda_b(0x66, 0x0f)) {
+ if (! test_mda_b(0x66, 0x0f)) {
return 0;
- } */
+ }
/* cursor low register */
- /* if (! test_mda_b(0x99, 0x0f)) {
+ if (! test_mda_b(0x99, 0x0f)) {
return 0;
- } */
+ }
+#endif
/* See if the card is a Hercules, by checking whether the vsync
* bit of the status register is changing. This test lasts for
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [RESEND] update chipsfb driver
Linus,
At present, drivers/video/chipsfb.c can only be used on PPC, and it
doesn't compile even on PPC. The patch below makes it compile, and by
changing it to use the generic inb/outb, means that there is at least
a chance it can be used on other platforms. The patch is against
2.4.3-pre7, could you apply it please?
Paul.
diff -urN linux/drivers/video/chipsfb.c pmac/drivers/video/chipsfb.c
--- linux/drivers/video/chipsfb.c Thu Feb 22 14:25:27 2001
+++ pmac/drivers/video/chipsfb.cSat Mar 3 21:17:19 2001
@@ -29,17 +29,19 @@
#include
#include
#include
+#include
+
#ifdef CONFIG_FB_COMPAT_XPMAC
#include
-#endif
-#include
-#include
#include
+#endif
#ifdef CONFIG_PMAC_BACKLIGHT
#include
#endif
+#ifdef CONFIG_PMAC_PBOOK
#include
#include
+#endif
#include
#include
@@ -56,14 +58,13 @@
struct {
__u8 red, green, blue;
} palette[256];
+ struct pci_dev *pdev;
unsigned long frame_buffer_phys;
__u8 *frame_buffer;
unsigned long blitter_regs_phys;
__u32 *blitter_regs;
unsigned long blitter_data_phys;
__u8 *blitter_data;
- unsigned long io_base_phys;
- __u8 *io_base;
struct fb_info_chips *next;
#ifdef CONFIG_PMAC_PBOOK
unsigned char *save_framebuffer;
@@ -74,10 +75,10 @@
};
#define write_ind(num, val, ap, dp)do { \
- out_8(p->io_base + (ap), (num)); out_8(p->io_base + (dp), (val)); \
+ outb((num), (ap)); outb((val), (dp)); \
} while (0)
#define read_ind(num, var, ap, dp) do { \
- out_8(p->io_base + (ap), (num)); var = in_8(p->io_base + (dp)); \
+ outb((num), (ap)); var = inb((dp)); \
} while (0);
/* extension registers */
@@ -97,10 +98,10 @@
#define read_sr(num, var) read_ind(num, var, 0x3c4, 0x3c5)
/* attribute registers - slightly strange */
#define write_ar(num, val) do { \
- in_8(p->io_base + 0x3da); write_ind(num, val, 0x3c0, 0x3c0); \
+ inb(0x3da); write_ind(num, val, 0x3c0, 0x3c0); \
} while (0)
#define read_ar(num, var) do { \
- in_8(p->io_base + 0x3da); read_ind(num, var, 0x3c0, 0x3c1); \
+ inb(0x3da); read_ind(num, var, 0x3c0, 0x3c1); \
} while (0)
static struct fb_info_chips *all_chips;
@@ -117,7 +118,7 @@
*/
int chips_init(void);
-static void chips_of_init(struct device_node *dp);
+static void chips_pci_init(struct pci_dev *dp);
static int chips_get_fix(struct fb_fix_screeninfo *fix, int con,
struct fb_info *info);
static int chips_get_var(struct fb_var_screeninfo *var, int con,
@@ -253,29 +254,29 @@
#endif /* CONFIG_PMAC_BACKLIGHT */
/* get the palette from the chip */
for (i = 0; i < 256; ++i) {
- out_8(p->io_base + 0x3c7, i);
+ outb(i, 0x3c7);
udelay(1);
- p->palette[i].red = in_8(p->io_base + 0x3c9);
- p->palette[i].green = in_8(p->io_base + 0x3c9);
- p->palette[i].blue = in_8(p->io_base + 0x3c9);
+ p->palette[i].red = inb(0x3c9);
+ p->palette[i].green = inb(0x3c9);
+ p->palette[i].blue = inb(0x3c9);
}
for (i = 0; i < 256; ++i) {
- out_8(p->io_base + 0x3c8, i);
+ outb(i, 0x3c8);
udelay(1);
- out_8(p->io_base + 0x3c9, 0);
- out_8(p->io_base + 0x3c9, 0);
- out_8(p->io_base + 0x3c9, 0);
+ outb(0, 0x3c9);
+ outb(0, 0x3c9);
+ outb(0, 0x3c9);
}
} else {
#ifdef CONFIG_PMAC_BACKLIGHT
set_backlight_enable(1);
#endif /* CONFIG_PMAC_BACKLIGHT */
for (i = 0; i < 256; ++i) {
- out_8(p->io_base + 0x3c8, i);
+ outb(i, 0x3c8);
udelay(1);
- out_8(p->io_base + 0x3c9, p->palette[i].red);
- out_8(p->io_base + 0x3c9, p->palette[i].green);
- out_8(p->io_base + 0x3c9, p->palette[i].blue);
+ outb(p->palette[i].red, 0x3c9);
+ outb(p->palette[i].green, 0x3c9);
+ outb(p->palette[i].blue, 0x3c9);
}
}
}
@@ -307,11 +308,11 @@
p->palette[regno].red = red;
p->palette[regno].green = green;
p->palette[regno].blue = blue;
- out_8(p->io_base + 0x3c8, regno);
+ outb(regno, 0x3c8);
udelay(1);
- out_8(p->io_base + 0x3c9, red);
- out_8(p->io_base + 0x3c9, green);
- out_8(p->io_base + 0x3c9, blue);
+ outb(red, 0x3c9);
+ outb(green, 0x3c9)
SMP bugs (2.4.0-ac11, 2.4.1) with traces from the serial console(fwd)
Apparently, linux-smp is rather dead, so I'll repost it here.
Paul
-- Forwarded message --
Date: Tue, 27 Mar 2001 12:40:23 +0200 (MET DST)
From: Paul Wouters <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: SMP bugs (2.4.0-ac11, 2.4.1) with traces from the serial console (fwd)
We've had quite some problems with one of our SMP servers, a dual P-III 333,
Asus mainboard.
I'll post some traces, which I got over the serial console. Machine would
normally be 99% dead in the water, no serial console input worked anymore
(eg sending a break for SysRq-u and SysRq-b would not work).
The machine is colocated, so I don't know if keyboard input was still
accepted. Userland would be quite dead, and networking would bein the worst
state imaginable. It would send out ICMP (eg ping works), and it would send
exactly one packet for each TCP connection (eg it would send syn-ack, but
then be silent forever).
When running 2.4.0-ac11 it would be reasonable stable (1-2 weeks of uptime).
On 2.4.1 it would die within hours. 2.4.2 didn't compile for me.
One of the things I noticed was that the system was also leaking fd's. I
would get messages like "VFS: file-max limit 4096 reached" and raising them
would only help for a day or so, "VFS: file-max limit 16384 reached"
This usually happened when I was doing something tough, heavy NFS stuff one
time, and heavy dns (webstats resolving an masse) at other times.
Below are the traces of the two kernels involved. If it is useful, I can
supply more data, if you tell me what else you need. But I'm fearing the
length of this email as it is.
Please CC: me on any replies, as I'm not on the linux-smp list.
Cheers,
Paul
On 2.4.0-ac11:
kernel BUG at page_alloc.c:191!
invalid operand:
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010092
eax: 0020 ebx: cfff9400 ecx: 0001 edx: 002f
esi: c0296c40 edi: c0296c18 ebp: esp: cd19be44
ds: 0018 es: 0018 ss: 0018
Process named-xfer (pid: 17095, stackpage=cd19b000)
Stack: c0240eab c0241059 00bf c0296c18 c0296df0 0001 c5dad508 0007
c0296d94 c0296d90 0286 c0296c18 c012f915 c15e22a0 c6296dc0
0001 c5dad508 c6296dc0 0005 0001 c0296dec c0124c77
Call Trace: [] [] [] [] []
[] []
[] []
Code: 0f 0b 83 c4 0c 89 f6 8b 53 04 8b 03 89 50 04 89 02 89 5c 24
>>EIP; c012f579<=
Trace; c012f915 <__alloc_pages+ed/2ec>
Trace; c0124c77
Trace; c0124cf4
Trace; c0124eaa
Trace; c0114447
Trace; c01142e8
Trace; c0125468
Trace; c010dc6f
Trace; c01090dc
Code; c012f579
<_EIP>:
Code; c012f579<=
0: 0f 0b ud2a <=
Code; c012f57b
2: 83 c4 0c add$0xc,%esp
Code; c012f57e
5: 89 f6 mov%esi,%esi
Code; c012f580
7: 8b 53 04 mov0x4(%ebx),%edx
Code; c012f583
a: 8b 03 mov(%ebx),%eax
Code; c012f585
c: 89 50 04 mov%edx,0x4(%eax)
Code; c012f588
f: 89 02 mov%eax,(%edx)
Code; c012f58a
11: 89 5c 24 00 mov%ebx,0x0(%esp,1)
NMI Watchdog detected LOCKUP on CPU1, registers:
CPU:1
EIP:0010:[]
EFLAGS: 0082
eax: ebx: c0296c18 ecx: c0296c18 edx:
esi: c0296c40 edi: 0001 ebp: esp: c50c7e88
ds: 0018 es: 0018 ss: 0018
Process syslogd (pid: 469, stackpage=c50c7000)
Stack: c0296c18 c0296e18 0001 cfdc1ea4 0007 c0296d94 c0296d90 0292
c0296c18 c012f915 c50c7f58 c14e2d80 cfdc1ea4
cf193ea0 0007 0001 c0296e14 c012fb28 c01444e3 ce706cc0 c14e2d80
Call Trace: [] [] [] [] []
[] []
[]
Code: 80 39 00 f3 90 7e f9 e9 84 30 f0 ff 80 3f 00 f3 90 7e f9 e9
>>EIP; c022c492<=
Trace; c012f915 <__alloc_pages+ed/2ec>
Trace; c012fb28 <__get_free_pages+14/20>
Trace; c01444e3 <__pollwait+33/94>
Trace; c01e9a6f
Trace; c01e62cb
Trace; c014474b
Trace; c0144c92
Trace; c0108fab
Code; c022c492
<_EIP>:
Code; c022c492<=
0: 80 39 00 cmpb $0x0,(%ecx) <=
Code; c022c495
3: f3 90 repz nop
Code; c022c497
5: 7e f9 jle0 <_EIP>
Code; c022c499
7: e9 84 30 f0 ffjmpfff03090 <_EIP+0xfff03090> c012f522
Code; c022c49e
c: 80 3f 00 cmpb $0x0,(%edi)
Code; c022c4a1
f: f3 90 repz nop
Code; c022c4a3
11: 7e f9 jlec <_EIP+0xc> c022c49e
Code; c022c4a5
13: e9 00 00 00 00jmp18 <_EIP+0x18> c022c4aa
Crash number 2, same kernel:
EIP: [] [] [] [] []
[]
Code: 0f 0b 83 c4 0c 90 89 d8 eb 1c 45 83 c6 0c 83 fd 09
Re: Larger dev_t
On Tue, 27 Mar 2001, Dan Hollis wrote:
> On Tue, 27 Mar 2001, H. Peter Anvin wrote:
> > c) Make sure chown/chmod/link/symlink/rename/rm etc does the right thing,
> > without the need for "tar hacks" or anything equivalently gross.
>
> write-through filesystem, like overlaying a r/w ext2 on top of an iso9660
> fs.
functionality to do this is in devfs and devfsd already.
there are 2 ways:
1. devfs on /dev, maintain state in /dev-state.
2. regular ext2 (devfs naming style) /dev and devfs mounted on, eg,
/devfs for hotplug and module load/unload updates
1:
/dev-state -> regular ext2
/dev -> devfs
use the CREATE, CHANGE and REGISTER hooks that devfs has to
allow devfsd to transparently copy changes in /dev to the ext2
/dev-state. See the example devfsd.conf for appropriate entries, eg:
REGISTER .* COPY/dev-state/$devname $devpath
CHANGE .* COPY$devpath /dev-state/$devname
CREATE .* COPY$devpath /dev-state/$devname
2:
/dev -> regular ext2
/devfs -> devfs
use the devfs hooks for REGISTER and UNREGISTER to have devfsd update
the static /dev whenever hotplug events occur. Eg:
REGISTER.* COPY${mntpnt}/$devname /dev/$devname
UNREGISTER .* CFUNCTION GLOBAL unlink /dev/$devname
seems to work for me:
[root@fogarty /devfs]# ls -l /dev{,fs}/misc/nvram
ls: /dev/misc/nvram: No such file or directory
ls: /devfs/misc/nvram: No such file or directory
[root@fogarty /devfs]# modprobe nvram
[root@fogarty /devfs]# ls -l /dev{,fs}/misc/nvram
crw-r-1 root root 10, 144 Jan 1 1970 /devfs/misc/nvram
crw-r-1 root root 10, 144 Mar 28 01:56 /dev/misc/nvram
[root@fogarty /devfs]# rmmod nvram
[root@fogarty /devfs]# ls -l /dev{,fs}/misc/nvram
ls: /dev/misc/nvram: No such file or directory
ls: /devfs/misc/nvram: No such file or directory
> -Dan
i prefer option 2 as /dev state is then not dependent on devfsd being
there and it just sidesteps the whole permissions issue. if devfsd
doesn't start then i still have a fully functional /dev.
but anyway... there seems to be loads of scope to do lots of
different things with devfsd, plus NIS support. :)
regards,
--
Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED]
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
---
Fortune:
Premature optimization is the root of all evil.
-- D.E. Knuth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
1 (autoclean) [visor usbserial uhci]
from Debian's /var/log/ksymoops
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
Under plain -ac12:
manetheren:/var/log/ksymoops# cat /proc/ioports
-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
0376-0376 : ide1
0378-037a : parport0
037b-037f : parport0
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(set)
0cf8-0cff : PCI conf1
d000-dfff : PCI Bus #01
d800-d8ff : Lite-On Communications Inc LNE100TX
d800-d8ff : eth0
df00-df3f : Ensoniq ES1371 [AudioPCI-97]
df00-df3f : es1371
ef80-ef9f : Intel Corporation 82801AA USB
ef80-ef9f : usb-uhci
efa0-efaf : Intel Corporation 82801AA SMBus
ffa0-ffaf : Intel Corporation 82801AA IDE
ffa0-ffa7 : ide0
ffa8-ffaf : ide1
manetheren:/var/log/ksymoops# cat /proc/iomem
-0009fbff : System RAM
0009fc00-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-07eb : System RAM
0010-001cd2c5 : Kernel code
001cd2c6-0020c2ff : Kernel data
07ec-07ef7fff : ACPI Tables
07ef8000-07ef : ACPI Non-volatile Storage
f6a0-f6af : PCI Bus #01
f800-fbff : Intel Corporation 82810-DC100 CGC [Chipset Graphics Controller]
ff80-ff8f : PCI Bus #01
ff8ffc00-ff8ffcff : Lite-On Communications Inc LNE100TX
ff8ffc00-ff8ffcff : eth0
ffa8-ffaf : Intel Corporation 82810-DC100 CGC [Chipset Graphics Controller]
ffb8-ffbf : reserved
fff0- : reserved
[7.5.] PCI information ('lspci -vvv' as root)
manetheren:/var/log/ksymoops# lspci -vvv
00:00.0 Host bridge: Intel Corporation 82810-DC100 GMCH [Graphics Memory Controller
Hub] (rev 02)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- Reset- FastB2B-
00:1f.0 ISA bridge: Intel Corporation 82801AA ISA Bridge (LPC) (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping-
SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- i_size = offset;
if (inode->i_op && inode->i_op->truncate)
+ {
+ /* This doesnt scale but it is meant to be a 2.4 invariant */
+ lock_kernel();
inode->i_op->truncate(inode);
+ unlock_kernel();
+ }
return 0;
out:
return -EFBIG;
A few lines earlier in this function, inode->i_op->truncate() is called
without lock_kernel(). Should it also have a lock_kernel(), or is it not
needed there?
--
Paul Cassella
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
From: "Krzysztof Halasa" <[EMAIL PROTECTED]>
> +struct hdlc_physical /* 10 bytes */
> +{
> + unsigned int interface;
> + unsigned int clock_rate;
> + unsigned short clock_type;
> +};
What about encoding (NRZ/NRZI)?
Plus I think the CRC type would be a good idea for
raw HDLC mode. (CRC-16, CRC-32, no CRC)
Paul Fulghum
[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: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
Earlier today, I wrote > and no sysrq keys other than B worked; I didn't hear disk activity > after S, and the disks weren't unmounted. Nothing made it to the Of course, when I rebooted this time (after SysRQ S,U,B), all the filesystems were clean. Nothing in the logs this time either though. > When I get home and reboot (following this most recent hang :( ), I'll > put the diff, .config, and more stuff from /proc at > http://manetheren.eigenray.com/~fortytwo/crash-12-18.2 This is now there. -- Paul Cassella - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
On Thu, 29 Mar 2001, Alan Cox wrote: > Was anything between 12 and 18 stable ? I didn't actually try them; I jumped right from 12 to 18, and when that and 19 died, I went back to 12. But a quick look suggests that the entire patch I'd applied to 12 and got a hang with was in 13, including the pm.c change. I also haven't tried anything after 24; is it likely to have been fixed? -- Paul Cassella - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: configuring net interfaces
> > Parameters for retransmission of a trame specified in Q922. t200 is the > > timeout value and n200 the maximal number of retransmissions. They can > > be negocied and default to t200=1,5s, n200=3. > > Hmm... I've taken a look at it, but it seems to me that they are only > used with "acknowledged multiple frame operation". Isn't it for ISDN only? > With Frame Relay, we rather use unacknowledged transfers and UI frames. > > Of course, if we have an implementation using t200, n200 or other > parameters, they should be added to the structure. It makes sense to me to defer adding the extra parameters (as you suggest) until there is actual support for SVCs or acknowledged mode over PVCs. The majority of what I've seen is PVC/UI. Paul Fulghum [EMAIL PROTECTED] Microgate Corporation www.microgate.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: Serial, 115Kbps, 2.2, 2.4
On Sun, 1 Apr 2001, Tom Sightler wrote: > III) I get a fair number of dropped packets at 115Kbps, enough to cause > problems and a significant speed decrease. Simply dropping the serial port > rate to 56K seems to solve the problem. does the system have IDE disks? (DEC Venturis GL.. should be) Try hdparm -u on all your IDE disks... should improve things. > Later, > Tom regards, -- Paul Jakma [EMAIL PROTECTED] [EMAIL PROTECTED] PGP5 key: http://www.clubi.ie/jakma/publickey.txt --- Fortune: What I want is all of the power and none of the responsibility. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
On Wed, 28 Mar 2001, Paul Cassella wrote:
> Hangs under 2.4.2-ac{18,19,24} that do not happen under -ac12.
I've been running -ac27 for over 5 days, and it's been fine, so this seems
to have been fixed.
--
Paul Cassella
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: uninteruptable sleep (D state => load_avrg++)
On Wed, 4 Apr 2001, christophe barbe wrote: > The sleep should certainly be interruptible and I that's what I > said to the GFS guy. But what the reason to increment the load > average for each D process ? from a philosical POV: they are processes that will be runnable as soon as the kernel returns to them. no idea if there are technical reasons for it. > > Thanks, > Christophe --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: uninteruptable sleep (D state => load_avrg++)
On Wed, 4 Apr 2001, christophe barbe wrote: > From me, a POV without technical reasons is not a philosical one > but more certainly an historical one. there may be (and indeed probably are) good technical reasons, however i am not well enough informed to say what they are. > Process that will be runnable are not participating to the load so > why incrementing the load average. As i understand it: load avg by nature is a measure of how many processes are 'runnable' (ie waiting to run) over time. a process waiting for the kernel to complete IO will indeed be runnable as soon as the kernel is finished. instead of waiting for CPU time (as with processes marked R), instead these processes are waiting for kernel to complete. > Moreover if a process should be > in state D only for a short time, the influence of the > incrementation should be near null for an AVERAGE value. because the number of processes asleep, waiting on kernel to complete IO may reasonably be considered to be a load. imagine a box with a bunch of processes that do almost nothing but call on the kernel to do IO. If you only count the runnable state towards load_avg then your load_avg will be very low, even though your box is swamped - you are ignoring the work of the kernel. if you count D towards load_avg then it will reflect this abstract 'load' concept more accurately. Ie, counting D towards load_avg is a way of taking kernel IO work into account when calculating the load average figures. > What's the technical reason behind this load_avrg++ ??? > > Christophe > --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: a quest for a better scheduler
> Just a quick comment. Andrea, unless your machine has some hardware > that imply pernode runqueues will help (nodelevel caches etc), I fail > to understand how this is helping you ... here's a simple theory though. > If your system is lightly loaded, your pernode queues are actually > implementing some sort of affinity, making sure processes stick to > cpus on nodes where they have allocated most of their memory on. I am > not sure what the situation will be under huge loads though. Exactly. If a given task has run on a particular nodes for a while, its memory will tend to be allocated on that node. So preferentially running it on another CPU on that same node should get you better memory latency than would running it on some other node's CPUs. In addition, continuing to run the task on a particular node means that more of that task's memory is from that node, which again means good memory latency. In contrast, if you move a task back and forth between nodes, it can end up with its memory spread over many nodes, which means that it does not get good memory latency no matter where you run it. Thanx, Paul > As I have mentioned to some people before, percpu/pernode/percpuset/global > runqueues probably all have their advantages and disadvantages, and their > own sweet spots. Wouldn't it be really neat if a system administrator > or performance expert could pick and choose what scheduler behavior he > wants, based on how the system is going to be used? > > Kanoj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 for 2.5] preemptible kernel
Please accept my apologies if I am missing something basic, but...
1. On a busy system, isn't it possible for a preempted task
to stay preempted for a -long- time, especially if there are
lots of real-time tasks in the mix?
2. Isn't it possible to get in trouble even on a UP if a task
is preempted in a critical region? For example, suppose the
preempting task does a synchronize_kernel()?
If I understand the preemptible kernel patch, suppressing preemption
is quite cheap -- just increment preempt_count before and decrement
it after, with no locks, atomic operations, or disabling of interrupts
required. I understand that disabling preemption for any long time
is a Bad Thing, however, Dipankar's patch is able to detect situations
where preemption has been suppressed for too long. In addition, Rusty's
original synchronize_kernel() patch is much simpler than the two that
wait for preempted tasks to reach a voluntary context switch.
What am I missing here?
Thanx, Paul
> > Here is an attempt at a possible version of synchronize_kernel() that
> > should work on a preemptible kernel. I haven't tested it yet.
>
> It's close, but...
>
> Those who suggest that we don't do preemtion on SMP make this much
> easier (synchronize_kernel() is a NOP on UP), and I'm starting to
> agree with them. Anyway:
>
> > if (p->state == TASK_RUNNING ||
> > (p->state == (TASK_RUNNING|TASK_PREEMPTED))) {
> > p->flags |= PF_SYNCING;
>
> Setting a running task's flags brings races, AFAICT, and checking
> p->state is NOT sufficient, consider wait_event(): you need p->has_cpu
> here I think. You could do it for TASK_PREEMPTED only, but you'd have
> to do the "unreal priority" part of synchronize_kernel() with some
> method to say "don't preempt anyone", but it will hurt latency.
> Hmmm...
>
> The only way I can see is to have a new element in "struct
> task_struct" saying "syncing now", which is protected by the runqueue
> lock. This looks like (and I prefer wait queues, they have such nice
> helpers):
>
> static DECLARE_WAIT_QUEUE_HEAD(syncing_task);
> static DECLARE_MUTEX(synchronize_kernel_mtx);
> static int sync_count = 0;
>
> schedule():
> if (!(prev->state & TASK_PREEMPTED) && prev->syncing)
> if (--sync_count == 0) wake_up(&syncing_task);
>
> synchronize_kernel():
> {
> struct list_head *tmp;
> struct task_struct *p;
>
> /* Guard against multiple calls to this function */
> down(&synchronize_kernel_mtx);
>
> /* Everyone running now or currently preempted must
>voluntarily schedule before we know we are safe. */
> spin_lock_irq(&runqueue_lock);
> list_for_each(tmp, &runqueue_head) {
> p = list_entry(tmp, struct task_struct, run_list);
> if (p->has_cpu || p->state
== (TASK_RUNNING|TASK_PREEMPTED)) {
> p->syncing = 1;
> sync_count++;
> }
> }
> spin_unlock_irq(&runqueue_lock);
>
> /* Wait for them all */
> wait_event(syncing_task, sync_count == 0);
> up(&synchronize_kernel_mtx);
> }
>
> Also untested 8),
> Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 for 2.5] preemptible kernel
Andi, thank you for the background! More comments interspersed... > On Fri, Apr 06, 2001 at 04:52:25PM -0700, Paul McKenney wrote: > > 1. On a busy system, isn't it possible for a preempted task > > to stay preempted for a -long- time, especially if there are > > lots of real-time tasks in the mix? > > The problem you're describing is probably considered too hard to > solve properly (bad answer, but that is how it is currently) > > Yes there is. You can also force a normal (non preemptive) kernel > into complete livelock by just giving it enough network traffic > to do, so that it always works in the high priority network > softirq or doing the same with some other interrupt. > > Just when this happens a lot of basic things will stop working (like > page cleaning, IO flushing etc.), so your callbacks or module unloads > not running are probably the least of your worries. > > The same problem applies to a smaller scale to real time processes; > kernel services normally do not run real-time, so they can be starved. > > Priority inversion is not handled in Linux kernel ATM BTW, there > are already situations where a realtime task can cause a deadlock > with some lower priority system thread (I believe there is at least > one case of this known with realtime ntpd on 2.4) I see your point here, but need to think about it. One question: isn't it the case that the alternative to using synchronize_kernel() is to protect the read side with explicit locks, which will themselves suppress preemption? If so, why not just suppress preemption on the read side in preemptible kernels, and thus gain the simpler implementation of synchronize_kernel()? You are not losing any preemption latency compared to a kernel that uses traditional locks, in fact, you should improve latency a bit since the lock operations are more expensive than are simple increments and decrements. As usual, what am I missing here? ;-) > > 2. Isn't it possible to get in trouble even on a UP if a task > > is preempted in a critical region? For example, suppose the > > preempting task does a synchronize_kernel()? > > Ugly. I guess one way to solve it would be to readd the 2.2 scheduler > taskqueue, and just queue a scheduler callback in this case. Another approach would be to define a "really low" priority that noone other than synchronize_kernel() was allowed to use. Then the UP implementation of synchronize_kernel() could drop its priority to this level, yield the CPU, and know that all preempted tasks must have obtained and voluntarily yielded the CPU before synchronize_kernel() gets it back again. I still prefer suppressing preemption on the read side, though I suppose one could claim that this is only because I am -really- used to it. ;-) Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel
> > I see your point here, but need to think about it. One question: > > isn't it the case that the alternative to using synchronize_kernel() > > is to protect the read side with explicit locks, which will themselves > > suppress preemption? If so, why not just suppress preemption on the read > > side in preemptible kernels, and thus gain the simpler implementation > > of synchronize_kernel()? You are not losing any preemption latency > > compared to a kernel that uses traditional locks, in fact, you should > > improve latency a bit since the lock operations are more expensive than > > are simple increments and decrements. As usual, what am I missing > > here? ;-) > > Already preempted tasks. But if you are suppressing preemption in all read-side critical sections, then wouldn't any already-preempted tasks be guaranteed to -not- be in a read-side critical section, and therefore be guaranteed to be unaffected by the update (in other words, wouldn't such tasks not need to be waited for)? > > Another approach would be to define a "really low" priority that noone > > other than synchronize_kernel() was allowed to use. Then the UP > > implementation of synchronize_kernel() could drop its priority to > > this level, yield the CPU, and know that all preempted tasks must > > have obtained and voluntarily yielded the CPU before synchronize_kernel () > > gets it back again. > > Or "never", because I'm running RC5 etc. 8(. U... Good point! Never mind use of low priorities in UP kernels for synchronize_kernel()... Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel
> > > > 2. Isn't it possible to get in trouble even on a UP if a task > > > > is preempted in a critical region? For example, suppose the > > > > preempting task does a synchronize_kernel()? > > > > > > Ugly. I guess one way to solve it would be to readd the 2.2 scheduler > > > taskqueue, and just queue a scheduler callback in this case. > > > > Another approach would be to define a "really low" priority that noone > > other than synchronize_kernel() was allowed to use. Then the UP > > implementation of synchronize_kernel() could drop its priority to > > this level, yield the CPU, and know that all preempted tasks must > > have obtained and voluntarily yielded the CPU before synchronize_kernel () > > gets it back again. > > That just would allow nasty starvation, e.g. when someone runs a cpu intensive > screensaver or a seti-at-home. Good point! I hereby withdraw my suggested use of ultra-low priorities for UP implementations of synchronize_kernel(). ;-) > > I still prefer suppressing preemption on the read side, though I > > suppose one could claim that this is only because I am -really- > > used to it. ;-) > > For a lot of reader cases non-preemption by threads is guaranteed anyways -- > e.g. anything that runs in interrupts, timers, tasklets and network softirq. > I think that already covers a lot of interesting cases. Good point again! For example, this does cover most of the TCP/IP cases, right? Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel
> > As you've observed, with the approach of waiting for all pre-empted tasks > > to synchronize, the possibility of a task staying pre-empted for a long > > time could affect the latency of an update/synchonize (though its hard for > > me to judge how likely that is). > > It's very unlikely on a system that doesn't already have problems with > CPU starvation because of runaway real-time tasks or interrupt handlers. Agreed! > First, preemption is a comparitively rare event with a mostly > timesharing load, typically from 1% to 10% of all context switches. Again, agreed! > Second, the scheduler should not penalize the preempted task for being > preempted, so that it should usually get to continue running as soon as > the preempting task is descheduled, which is at most one timeslice for > timesharing tasks. The algorithms we have been looking at need to have absolute guarantees that earlier activity has completed. The most straightforward way to guarantee this is to have the critical-section activity run with preemption disabled. Most of these code segments either take out locks or run with interrupts disabled anyway, so there is little or no degradation of latency in this case. In fact, in many cases, latency would actually be improved due to removal of explicit locking primitives. I believe that one of the issues that pushes in this direction is the discovery that "synchronize_kernel()" could not be a nop in a UP kernel unless the read-side critical sections disable preemption (either in the natural course of events, or artificially if need be). Andi or Rusty can correct me if I missed something in the previous exchange... The read-side code segments are almost always quite short, and, again, they would almost always otherwise need to be protected by a lock of some sort, which would disable preemption in any event. Thoughts? Thanx, Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Lse-tech] Re: [PATCH for 2.5] preemptible kernel
> On Tue, 10 Apr 2001, Paul McKenney wrote: > > The algorithms we have been looking at need to have absolute guarantees > > that earlier activity has completed. The most straightforward way to > > guarantee this is to have the critical-section activity run with preemption > > disabled. Most of these code segments either take out locks or run > > with interrupts disabled anyway, so there is little or no degradation of > > latency in this case. In fact, in many cases, latency would actually be > > improved due to removal of explicit locking primitives. > > > > I believe that one of the issues that pushes in this direction is the > > discovery that "synchronize_kernel()" could not be a nop in a UP kernel > > unless the read-side critical sections disable preemption (either in > > the natural course of events, or artificially if need be). Andi or > > Rusty can correct me if I missed something in the previous exchange... > > > > The read-side code segments are almost always quite short, and, again, > > they would almost always otherwise need to be protected by a lock of > > some sort, which would disable preemption in any event. > > > > Thoughts? > > Disabling preemption is a possible solution if the critical section is short > - less than 100us - otherwise preemption latencies become a problem. Seems like a reasonable restriction. Of course, this same limit applies to locks and interrupt disabling, right? > The implementation of synchronize_kernel() that Rusty and I discussed > earlier in this thread would work in other cases, such as module > unloading, where there was a concern that it was not practical to have > any sort of lock in the read-side code path and the write side was not > time critical. True, but only if the synchronize_kernel() implementation is applied to UP kernels, also. Thanx, Paul > Nigel Gamble[EMAIL PROTECTED] > Mountain View, CA, USA. http://www.nrg.org/ > > MontaVista Software [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: /dev/rtc not working on ASUS A7V133
Jan Niehusmann wrote:
> But I have a correction: The problem does not only occurr if the system
> was started automatically by the bios, a manual 'soft off/soft on' sequence
> shows the same effect. Only 'hard off/hard on' (using the switch directly
> on the power supply) seems to work every time.
Can you run the following program when things are working and then when
they are not - i.e.
cmosdump > b4
# soft off / on
cmosdump > after
diff -u b4 after
The low registers (0, & 2 IIRC) are for sec and min, so expect changes
there - but of interest will be any changes in reg 0x0a and 0x0b.
Paul.
/*
*
* A quick hack to dump the CMOS RAM values from 0x0 to 0x7f. Note that
* some CMOS are only 0x40 in size, so edit accordingly. Released to
* the public under the terms and conditions of the Gnu General Public
* License (GPL) included herein by reference.
*
* Compile with:
* gcc -s -N -Wall -O cmosdump.c -o cmosdump
*
* Paul Gortmaker 07/95
*/
#define CMOS_SIZE 0x80
#include
#include
#include
#include
/*
* was on kernels prior to 2.2.19, so
* just define CMOS_READ/WRITE here independently and avoid the hassle.
*/
#define RTC_PORT(x) (0x70 + (x))
#define CMOS_READ(addr) ({ \
outb_p((addr),RTC_PORT(0)); \
inb_p(RTC_PORT(1)); \
})
#define CMOS_WRITE(val, addr) ({ \
outb_p((addr),RTC_PORT(0)); \
outb_p((val),RTC_PORT(1)); \
})
void binprint (unsigned short value);
void main(void) {
unsigned short addr, val;
val= iopl(3);
if (val) {
perror("iopl");
exit(errno);
}
printf("Addr:\tHex\tDec.\tBinary\n");
for (addr = 0; addr < CMOS_SIZE; addr++) {
val = CMOS_READ(addr);
printf("0x%X:\t0x%X\t%d\t",addr, val, val);
binprint(val);
printf("\n");
}
iopl(0);
} /*end*/
void binprint(unsigned short value) {
int bit;
for (bit=128;bit>0;bit/=2)
printf("%s", (value & bit) ? "1" : "0");
} /* end binprint */
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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/
[PATCH] sbpcd oops on merged requests
Two fixes here - 1st is to make the new max_drives its own separate
module parameter since the driver uses the existing sbpcd module
parameter internally for more than just module parameters .
2nd is more important - if you read more than 4 blocks from the
device, you will get a random crash - meaning you could mount a
cd and do "ls" and think it worked if that is all you did. Anything
more gets a rolling oops, EIP pointing off into outer space etc.
Tracked this down to the addition of the generic merge request
handling added to ll_rw_block in 2.3.41 (apparently nobody has
used this driver since then!!!) - it appears these conflict with
the molestation of the request list that sbpcd does from within.
Rather than attack sbpcd with a chainsaw, I went for the minimal
patch approach and simply disabled request merging. Lets face it,
performance is not an issue if you are using a 2x speed CD with
seek times you measure with a wall calendar.
Patch is against 2.4.2-pre3.
Paul.
--- drivers/cdrom/sbpcd.c~ Wed Feb 14 04:02:04 2001
+++ drivers/cdrom/sbpcd.c Wed Feb 14 04:09:55 2001
@@ -323,7 +323,7 @@
* Andrew J. Kroll <[EMAIL PROTECTED]> Wed Jul 26 04:24:10 EDT
2000
*
* 4.64 Fix module parameters - were being completely ignored.
- * Can also specify max_drives as 3rd setup int to get rid of
+ * Can also specify max_drives=N as a setup int to get rid of
* "ghost" drives on crap hardware (aren't they all?) Paul Gortmaker
*
* TODO
@@ -339,6 +339,15 @@
*
*/
+/*
+ * Trying to merge requests breaks this driver horribly (as in it goes
+ * boom and apparently has done so since 2.3.41). As it is a legacy
+ * driver for a horribly slow double speed CD on a hideous interface
+ * designed for polled operation, I won't loose any sleep in simply
+ * disallowing merging.Paul G. 02/2001
+ */
+#define DONT_MERGE_REQUESTS
+
#ifndef SBPCD_ISSUE
#define SBPCD_ISSUE 1
#endif SBPCD_ISSUE
@@ -476,7 +485,8 @@
#else
static int sbpcd[] = {CDROM_PORT, SBPRO}; /* probe with user's setup only */
#endif
-MODULE_PARM(sbpcd, "3i");
+MODULE_PARM(sbpcd, "2i");
+MODULE_PARM(max_drives, "i");
#define NUM_PROBE (sizeof(sbpcd) / sizeof(int))
@@ -5566,7 +5576,6 @@
#else
sbpcd_ioaddr = sbpcd[0];
sbpro_type = sbpcd[1];
- max_drives = sbpcd[2];
#endif
CDo_command=sbpcd_ioaddr;
@@ -5661,6 +5670,21 @@
msg(DBG_SEQ,"found SoundScape interface at %04X.\n", sbpcd_ioaddr);
return (0);
}
+
+#ifdef DONT_MERGE_REQUESTS
+static int dont_merge_requests_fn(request_queue_t *q, struct request *req,
+struct request *next, int max_segments)
+{
+ return 0;
+}
+
+static int dont_bh_merge_fn(request_queue_t *q, struct request *req,
+struct buffer_head *bh, int max_segments)
+{
+ return 0;
+}
+#endif
+
/*==*/
/*
* Test for presence of drive and initialize it.
@@ -5828,6 +5852,11 @@
#endif MODULE
}
blk_init_queue(BLK_DEFAULT_QUEUE(MAJOR_NR), DEVICE_REQUEST);
+#ifdef DONT_MERGE_REQUESTS
+ (BLK_DEFAULT_QUEUE(MAJOR_NR))->back_merge_fn = dont_bh_merge_fn;
+ (BLK_DEFAULT_QUEUE(MAJOR_NR))->front_merge_fn = dont_bh_merge_fn;
+ (BLK_DEFAULT_QUEUE(MAJOR_NR))->merge_requests_fn = dont_merge_requests_fn;
+#endif
blk_queue_headactive(BLK_DEFAULT_QUEUE(MAJOR_NR), 0);
read_ahead[MAJOR_NR] = buffers * (CD_FRAMESIZE / 512);
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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: [LK] Re: lkml subject line
On Tue, 13 Feb 2001, Mike A. Harris wrote: > If the above procmail filter doesn't work (untested) let me know > and I will MAKE it work. Windows users - tough luck - procmail > is open source - hire someone to port it... and even windows users can filter properly. netscape allows you to add custom headers to filter on. So absolutely no problems for netscape users. Those tied to outlook (as i was when i worked at compaq, until i found an exchange server that did imap) also have no need to complain as i managed to get it to filter l-k without problems -> use the outlook "Ru1eZ W1z4Rd" to setup a filter to catch anything "sent from linux-kernel@..." and then another filter to look for the l-k list info text included at the bottom of every mail. (this rule should be last.) hey presto, l-k neatly filtered away with Outlook. if you use an MUA that can't do filtering, well then there's something wrong with you --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] hd.c needs max_sectors set
[Yet more fixes from the OCD - Obsolete Cruft Department ]
Couldn't figure out why my el-lame-o testbox was generating random I/O
errors on large writes. I first suspected another booger cut loose in
the disk and generated the typical storm of errors since it has some
hundred or so bad blocks already... :)
I've supplied a similar fix for drivers/block/xd.c (untested, but
compiles & is straightforward). I'm tempted to just mark xd.c
with CONFIG_OBSOLETE anyway. Anybody really see using this in 2.4.x,
even if just as a boot device for a closet box?
Paul.
--- drivers/ide/hd.c~ Thu Feb 15 03:33:12 2001
+++ drivers/ide/hd.cThu Feb 15 06:55:28 2001
@@ -22,6 +22,9 @@
* This is now a lightweight ST-506 driver. (Paul Gortmaker)
*
* Modified 1995 Russell King for ARM processor.
+ *
+ * Bugfix: max_sectors must be <= 255 or the wheels tend to come
+ * off in a hurry once you queue things up - Paul G. 02/2001
*/
/*
@@ -106,6 +109,7 @@
static int hd_sizes[MAX_HD<<6];
static int hd_blocksizes[MAX_HD<<6];
static int hd_hardsectsizes[MAX_HD<<6];
+static int hd_maxsect[MAX_HD<<6];
static struct timer_list device_timer;
@@ -732,9 +736,11 @@
for(drive=0; drive < (MAX_HD << 6); drive++) {
hd_blocksizes[drive] = 1024;
hd_hardsectsizes[drive] = 512;
+ hd_maxsect[drive]=255;
}
blksize_size[MAJOR_NR] = hd_blocksizes;
hardsect_size[MAJOR_NR] = hd_hardsectsizes;
+ max_sectors[MAJOR_NR] = hd_maxsect;
#ifdef __i386__
if (!NR_HD) {
--- drivers/block/xd.c~ Mon Nov 20 04:16:39 2000
+++ drivers/block/xd.c Fri Feb 16 05:22:03 2001
@@ -28,6 +28,9 @@
* Recovered DMA access. Abridged messages. Added support for DTC5051CX,
* WD1002-27X & XEBEC controllers. Driver uses now some jumper settings.
* Extended ioctl() support.
+ *
+ * Bugfix: 15/02/01, Paul G. - inform queue layer of tiny xd_maxsect.
+ *
*/
#include
@@ -118,6 +121,7 @@
static struct hd_struct xd_struct[XD_MAXDRIVES << 6];
static int xd_sizes[XD_MAXDRIVES << 6], xd_access[XD_MAXDRIVES];
static int xd_blocksizes[XD_MAXDRIVES << 6];
+static int xd_maxsect[XD_MAXDRIVES << 6];
extern struct block_device_operations xd_fops;
@@ -241,6 +245,10 @@
else
printk("xd: unable to get IRQ%d\n",xd_irq);
}
+
+ /* xd_maxsectors depends on controller - so set after detection */
+ for(i=0; i<(XD_MAXDRIVES << 6); i++) xd_maxsect[i] = xd_maxsectors;
+ max_sectors[MAJOR_NR] = xd_maxsect;
for (i = 0; i < xd_drives; i++) {
xd_valid[i] = 1;
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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/
[PATCH] a more efficient BUG() macro
I was poking around in a vmlinux the other day and was surprised at the
amount of repetitive crap text that was in there. For example, try:
strings vmlinux|grep $PWD|wc -c
which gets some 70KB in my case - depends on strlen($PWD) obviously. The
culprit is BUG() in a static inline that is in a header file. In this
case cpp expands __FILE__ to the full path of the header file in question.
(IIRC there is a __BASEFILE__ that would be a better choice than __FILE__)
There is also some 5 to 10k worth of "kernel BUG at %s:%d!\n" scattered
through a typical vmlinux. Note that neither of these show up in [b]zImage
size since they compress to something like 99%, but they do cost memory once
the kernel is booted.
Anyway this small patch makes sure there is only one "kernel BUG..." string,
and dumps __FILE__ in favour of an address value since System.map data is
needed to make full use of the BUG() dump anyways. The memory stats of two
otherwise identical kernels:
Memory: 22004k/24576k available (1163k kernel code, 2184k reserved,
309k data, 64k init, 0k highmem)
Memory: 22076k/24576k available (1163k kernel code, 2112k reserved,
238k data, 64k init, 0k highmem)
so the lightweight BUG() nets a worthwhile (IMHO) saving of 72KB for this
particular kernel. (Which is even more than the __init goodies recover.)
Patch is against 2.4.2pre3 and is fully contained within i386 files.
I can supply a 2.2.x version of the patch if there is demand for it.
Paul.
diff -ur linux~/arch/i386/kernel/i386_ksyms.c linux/arch/i386/kernel/i386_ksyms.c
--- linux-g/arch/i386/kernel/i386_ksyms.c Thu Jan 11 09:06:12 2001
+++ linux-g-bug/arch/i386/kernel/i386_ksyms.c Thu Feb 15 03:50:18 2001
@@ -78,6 +78,7 @@
EXPORT_SYMBOL_NOVERS(__down_write_failed);
EXPORT_SYMBOL_NOVERS(__down_read_failed);
EXPORT_SYMBOL_NOVERS(__rwsem_wake);
+EXPORT_SYMBOL_NOVERS(bugstring);
/* Networking helper routines. */
EXPORT_SYMBOL(csum_partial_copy_generic);
/* Delay loops */
diff -ur linux~/arch/i386/kernel/setup.c linux/arch/i386/kernel/setup.c
--- linux-g/arch/i386/kernel/setup.cWed Feb 14 02:39:58 2001
+++ linux-g-bug/arch/i386/kernel/setup.cThu Feb 15 04:13:31 2001
@@ -105,6 +105,8 @@
char ignore_irq13; /* set if exception 16 works */
struct cpuinfo_x86 boot_cpu_data = { 0, 0, 0, 0, -1, 1, 0, 0, -1 };
+const char *bugstring="<1>kernel BUG at 0x%p\n";
+
unsigned long mmu_cr4_features;
/*
diff -ur linux~/include/asm-i386/page.h linux/include/asm-i386/page.h
--- linux-g/include/asm-i386/page.h Sat Dec 16 04:02:20 2000
+++ linux-g-bug/include/asm-i386/page.h Thu Feb 15 04:25:29 2001
@@ -86,10 +86,13 @@
* Tell the user there is some problem. Beep too, so we can
* see^H^H^Hhear bugs in early bootup as well!
*/
-#define BUG() do { \
- printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
+extern const char *bugstring; /* ...is in i386/kernel/setup.c - Paul G. */
+#define BUG() ({ \
+ __label__ bugaddr; \
+bugaddr: \
+ printk(bugstring, &&bugaddr); \
__asm__ __volatile__(".byte 0x0f,0x0b"); \
-} while (0)
+})
#define PAGE_BUG(page) do { \
BUG(); \
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] APMD on Linux 2.2.18 and include/linux/mc146818rtc.h
Marc Esipovich wrote: > > I've noticed this when attempting to build APMD, mc146818rtc.h has > a reference to a spinlock_t while asm/spinlock.h is not included. > > Patch follows: User space does not need to ever see any kernel spinlocks - you will find such a fix for this is in 2.2.19pre already though, so you can make use of that. Thanks for the report anyway, Paul. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux OS boilerplate
Scott Long wrote: > > I've been poring over the x86 boot code for a while now and I've been > considering writing a FAQ on the boot process (mostly for my own use, [...] > Does there exist an outline (detailed or not) of the boot process from > the point of BIOS bootsector load to when the kernel proper begins IIRC, there is some useful info contained within loadlin. Also, I found a doc by hpa called "THE LINUX/I386 BOOT PROTOCOL" in my local archive of cruft - I just assumed it was in Documentation/ but apparently it never made it there (yet). Paul. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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: [LONG RANT] Re: Linux stifles innovation...
On Mon, 19 Feb 2001, Henning P . Schmiedehausen wrote: > So, is it legal to put changes to a twin licensed driver in the Linux > kernel tree back into the same driver in the BSD tree? IANAL, but AIUI: if the changes are made the copyright holder then they may do whatever they want. (release the changes only under one licence, both, none, etc..) if small changes are made by a 3rd party (eg a patch) and submitted back to the copyright holder, then it is almost safe to presume that the copyright holder may incorporate those changes without ceding copyright in any way. (then see first point) if major changes are made by a 3rd party then (i think) 3rd party has copyright over their changes, and so, either: -copyright holder of the original work would need to comply with the licence of the derived work. (eg if GPL, then changes can't go back into the BSD version) or: - copyright holder of the original work would need express permission from the copyright holder of the derived work to use it under a different licence. but IANAL most obviously... :) > > Regards > Henning --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Running Bind 9 on Redhat 7
On Mon, 19 Feb 2001, Ansari wrote: > Hi !! > > I am configuring Bind 9 on Redhat 7 but unable to start the named. > Here is my /var/log message log: you have a config problem i think. > Feb 20 09:49:58 ns2 named[2005]: loading zones: no ttl you need to put: $TTL at the beginning of each zone file. oh, you're probably better off asking your questions on a bind specific list, rather than linux-kernel. regards, --paulj - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Better BUG() macro - take 2
Ok, it appears that some people want the __FILE__, __LINE__ (or equivalent)
in BUG() and some don't. Fair enough. I used the existing config option
CONFIG_DEBUG_ERRORS to allow people to choose. There was also interest
in having BUG() in a more sensible place (e.g. ) and the
arch specific part separate (I picked ).
This only deals with i386 - wanted to put this out for comment before
editing for the others. Change for other arch is simple though - just
remove BUG() from asm/page.h and put the *(int *)0=0; type part of what
was BUG() into asm/system.h as machine_bug(). Oh, and add the config
option to arch/*/config.in if it isn't already in use.
Feedback welcome (& thanks to those who already have done so)
Paul.
--- init/main.c~Tue Feb 20 00:58:55 2001
+++ init/main.c Tue Feb 20 02:45:55 2001
@@ -130,6 +130,9 @@
char *execute_command;
char root_device_name[64];
+#ifdef CONFIG_DEBUG_ERRORS
+const char *kernel_bug = "kernel BUG at %s: line %d!\n";
+#endif
static char * argv_init[MAX_INIT_ARGS+2] = { "init", NULL, };
static char * envp_init[MAX_INIT_ENVS+2] = { "HOME=/", "TERM=linux", NULL, };
--- include/asm-i386/page.h~Sat Dec 16 04:02:20 2000
+++ include/asm-i386/page.h Tue Feb 20 02:11:50 2001
@@ -82,15 +82,6 @@
#ifndef __ASSEMBLY__
-/*
- * Tell the user there is some problem. Beep too, so we can
- * see^H^H^Hhear bugs in early bootup as well!
- */
-#define BUG() do { \
- printk("kernel BUG at %s:%d!\n", __FILE__, __LINE__); \
- __asm__ __volatile__(".byte 0x0f,0x0b"); \
-} while (0)
-
#define PAGE_BUG(page) do { \
BUG(); \
} while (0)
--- arch/i386/config.in~Tue Feb 20 00:04:13 2001
+++ arch/i386/config.in Tue Feb 20 05:03:58 2001
@@ -366,4 +366,5 @@
#bool 'Debug kmalloc/kfree' CONFIG_DEBUG_MALLOC
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Verbose kernel error messages' CONFIG_DEBUG_ERRORS
endmenu
--- kernel/ksyms.c~ Wed Feb 14 02:42:16 2001
+++ kernel/ksyms.c Tue Feb 20 03:06:04 2001
@@ -463,6 +463,7 @@
EXPORT_SYMBOL(securebits);
EXPORT_SYMBOL(cap_bset);
EXPORT_SYMBOL(daemonize);
+EXPORT_SYMBOL(kernel_bug);
/* Program loader interfaces */
EXPORT_SYMBOL(setup_arg_pages);
--- include/asm-i386/system.h~ Tue Feb 20 00:02:07 2001
+++ include/asm-i386/system.h Tue Feb 20 05:08:41 2001
@@ -112,6 +112,8 @@
__asm__("movl %0,%%cr0": :"r" (x));
#define stts() write_cr0(8 | read_cr0())
+#define machine_bug() __asm__ __volatile__(".byte 0x0f,0x0b")
+
#endif /* __KERNEL__ */
static inline unsigned long get_limit(unsigned long segment)
--- include/linux/mount.h~ Mon Nov 20 04:14:06 2000
+++ include/linux/mount.h Tue Feb 20 04:54:09 2001
@@ -12,6 +12,8 @@
#define _LINUX_MOUNT_H
#ifdef __KERNEL__
+#include
+
#define MNT_VISIBLE1
struct vfsmount
--- include/linux/kernel.h~ Sat Dec 16 04:02:31 2000
+++ include/linux/kernel.h Tue Feb 20 05:19:04 2001
@@ -9,6 +9,7 @@
#include
#include
+#include
#include
/* Optimization barrier */
@@ -83,6 +84,22 @@
if (console_loglevel)
console_loglevel = 15;
}
+
+/*
+ * Multiple copies of the printk text, plus long pathnames from
+ * __FILE__ used to waste around 100k of memory! Paul G.
+ */
+#ifdef CONFIG_DEBUG_ERRORS
+extern const char *kernel_bug;
+#define SOURCE_LOCATION() printk(kernel_bug, __FILE__, __LINE__)
+#else
+#define SOURCE_LOCATION()
+#endif
+
+#define BUG() do { \
+ SOURCE_LOCATION(); \
+ machine_bug(); \
+} while (0)
#if DEBUG
#define pr_debug(fmt,arg...) \
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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/
(my) kgdb patch brakes compile.
Greetings,
I have been sucessfully able to take Amit S. Kale ([EMAIL PROTECTED])
kgdb patch for 2.4.0-test9, and create a patch for 2.4.0-test12.
I am trying to create a patch for 2.4.1.. but gcc barfs with the
following:
-
make[3]: Entering directory `/usr/src/linux-2.4.1-kgdb/kernel'
gcc -D__KERNEL__ -I/usr/src/linux-2.4.1-kgdb/include -Wall -Wstrict-prototypes -g
-pipe -mpreferred-stack-boundary=2 -march=i686-fno-omit-frame-pointer -c -o
sched.o sched.c
sched.c: In function `schedule':
sched.c:648: Invalid `asm' statement:
sched.c:648: fixed or forbidden register 6 (bp) was spilled for class GENERAL_REGS.
make[3]: *** [sched.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.4.1-kgdb/kernel'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.1-kgdb/kernel'
make[1]: *** [_dir_kernel] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.1-kgdb'
make: *** [stamp-build] Error 2
-
This can be traced to include/asm_i386/system.h.. (switch_to)
-
#define prepare_to_switch() do { } while(0)
#Define switch_to(prev,next,last) do { \
asm volatile("pushl %%esi\n\t" \
"pushl %%edi\n\t" \
"pushl %%ebp\n\t" \
"movl %%esp,%0\n\t"/* save ESP */ \
"movl %3,%%esp\n\t"/* restore ESP */ \
"movl $1f,%1\n\t" /* save EIP */ \
"pushl %4\n\t" /* restore EIP */ \
"jmp __switch_to\n"\
"1:\t" \
"popl %%ebp\n\t" \
"popl %%edi\n\t" \
"popl %%esi\n\t" \
:"=m" (prev->thread.esp),"=m" (prev->thread.eip), \
"=b" (last) \
:"m" (next->thread.esp),"m" (next->thread.eip),\
"a" (prev), "d" (next), \
"b" (prev)); \
} while (0)
-
Can someone explain what is the problem here? I'm assuming that it's
one of the compile options.
The kgdb patch puts the following in the top level makefile...
and put a switch for $(CONFIG_X86_REMOTE_DEBUG) in the config tool.
The kernel compiles fine without the patch, and with the patch,
with the option turned off.
-
CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes
ifeq ($(CONFIG_X86_REMOTE_DEBUG),y)
CFLAGS += -g
else
CFLAGS += -fomit-frame-pointer -O2 -fno-strict-aliasing
endif
Thanks,
Paul Schulz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: (my) kgdb patch brakes compile.
I think your problem is removing all optimization
(removing '-O2' when kgdb option is enabled).
I realize that debugging is easier with no optimization
but the kernel compile always spilled registers for me
when using -O0. I can do -O1 or -O2 with no problem.
Paul Fulghum [EMAIL PROTECTED]
Microgate Corporation www.microgate.com
- Original Message -----
From: "Paul Schulz" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 3:18 PM
Subject: (my) kgdb patch brakes compile.
> Greetings,
>
> I have been sucessfully able to take Amit S. Kale ([EMAIL PROTECTED])
> kgdb patch for 2.4.0-test9, and create a patch for 2.4.0-test12.
>
> I am trying to create a patch for 2.4.1.. but gcc barfs with the
> following:
>
> -
> make[3]: Entering directory `/usr/src/linux-2.4.1-kgdb/kernel'
>
gcc -D__KERNEL__ -I/usr/src/linux-2.4.1-kgdb/include -Wall -Wstrict-prototyp
es -g -pipe -mpreferred-stack-boundary=2 -march=i686-fno-omit-frame-poin
ter -c -o sched.o sched.c
> sched.c: In function `schedule':
> sched.c:648: Invalid `asm' statement:
> sched.c:648: fixed or forbidden register 6 (bp) was spilled for class
GENERAL_REGS.
> make[3]: *** [sched.o] Error 1
> make[3]: Leaving directory `/usr/src/linux-2.4.1-kgdb/kernel'
> make[2]: *** [first_rule] Error 2
> make[2]: Leaving directory `/usr/src/linux-2.4.1-kgdb/kernel'
> make[1]: *** [_dir_kernel] Error 2
> make[1]: Leaving directory `/usr/src/linux-2.4.1-kgdb'
> make: *** [stamp-build] Error 2
> -
> This can be traced to include/asm_i386/system.h.. (switch_to)
> -
> #define prepare_to_switch() do { } while(0)
> #Define switch_to(prev,next,last) do { \
> asm volatile("pushl %%esi\n\t" \
> "pushl %%edi\n\t" \
> "pushl %%ebp\n\t" \
> "movl %%esp,%0\n\t" /* save ESP */ \
> "movl %3,%%esp\n\t" /* restore ESP */ \
> "movl $1f,%1\n\t" /* save EIP */ \
> "pushl %4\n\t" /* restore EIP */ \
> "jmp __switch_to\n" \
> "1:\t" \
> "popl %%ebp\n\t" \
> "popl %%edi\n\t" \
> "popl %%esi\n\t" \
> :"=m" (prev->thread.esp),"=m" (prev->thread.eip), \
> "=b" (last) \
> :"m" (next->thread.esp),"m" (next->thread.eip), \
> "a" (prev), "d" (next), \
> "b" (prev)); \
> } while (0)
> -
> Can someone explain what is the problem here? I'm assuming that it's
> one of the compile options.
>
> The kgdb patch puts the following in the top level makefile...
> and put a switch for $(CONFIG_X86_REMOTE_DEBUG) in the config tool.
>
> The kernel compiles fine without the patch, and with the patch,
> with the option turned off.
> -
> CFLAGS := $(CPPFLAGS) -Wall -Wstrict-prototypes
> ifeq ($(CONFIG_X86_REMOTE_DEBUG),y)
> CFLAGS += -g
> else
> CFLAGS += -fomit-frame-pointer -O2 -fno-strict-aliasing
> endif
>
>
> Thanks,
> Paul Schulz
>
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message 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: CLOCAL and TIOCMIWAIT
> A customer has just brought to my attention that when you try to use the > TIOCMIWAIT ioctl with our boards and CLOCAL is enabled, you can't check > changes in the DCD signal. He also mentioned that that is possible with > the regular serial ports. > > As I understood, CLOCAL meant disabling DCD sensitivity, so if CLOCAL is > disabled, no changes in DCD will be passed from hardware driver to the > kernel or userspace. The way the serial driver is implemented, this is not > true (i.e. even with CLOCAL enabled, you can still see DCD changes through > the TIOCMIWAIT command). > > My question is: what's the correct interpretation of CLOCAL?? If the > serial driver's interpretation is the correct one, I'll be more than happy > to change the Cyclades' driver to comply with that, I just want to make > sure that this is the expected behavior before I patch the driver. > > Thanks in advance for your comments. > > Later, > Ivan I believe CLOCAL only governs how DCD is used (or ignored) when opening a port (must be active to complete open) and maintaining a connection (negation signals hangup). So CLOCAL controls the driver's 'interpretation' of DCD but TIOCMIWAIT monitors the signal transitions without regard to a predefined interpretation (let's the application decide what to do with DCD). Paul Fulghum [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] smaller parport_pc for non-PCI boxes
There is quite a bit of PCI stuff that gets compiled into parport_pc.c
even when CONFIG_PCI isn't enabled. This patch cuts down the size quite
a bit (more than 4k off the object, about 1k off the zImage) for the
older non-PCI machines which are typically resource starved anyway...
Patch is against 2.4.2
Paul.
--- drivers/parport/parport_pc.c~ Wed Feb 14 02:41:01 2001
+++ drivers/parport/parport_pc.cThu Mar 1 00:54:19 2001
@@ -11,6 +11,7 @@
* Cleaned up include files - Russell King <[EMAIL PROTECTED]>
* DMA support - Bert De Jonghe <[EMAIL PROTECTED]>
* Many ECP bugs fixed. Fred Barnes & Jamie Lokier, 1999
+ * More PCI support now conditional on CONFIG_PCI, 03/2001, Paul G.
*/
/* This driver should work with any hardware that is broadly compatible
@@ -2182,6 +2183,7 @@
}
+#ifdef CONFIG_PCI
/* Via support maintained by Jeff Garzik <[EMAIL PROTECTED]> */
static int __devinit sio_via_686a_probe (struct pci_dev *pdev)
{
@@ -2547,7 +2549,6 @@
static int __init parport_pc_init_superio (void)
{
-#ifdef CONFIG_PCI
const struct pci_device_id *id;
struct pci_dev *pdev;
@@ -2558,10 +2559,13 @@
return parport_pc_superio_info[id->driver_data].probe (pdev);
}
-#endif /* CONFIG_PCI */
return 0; /* zero devices found */
}
+#else
+static struct pci_driver parport_pc_pci_driver;
+static int __init parport_pc_init_superio(void) {return 0;}
+#endif /* CONFIG_PCI */
/* This is called by parport_pc_find_nonpci_ports (in asm/parport.h) */
static int __init __attribute__((unused))
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.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/
