* Re: Linux 2.4.21-pre1 IDE
From: Erik Andersen @ 2002-12-12 1:35 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: lkml
In-Reply-To: <Pine.LNX.4.50L.0212101834240.23096-100000@freak.distro.conectiva>
On Tue Dec 10, 2002 at 06:37:14PM -0200, Marcelo Tosatti wrote:
>
> So here goes the first pre of 2.4.21 including the new IDE code merged
> from Alan's tree.
>
> Test it carefully, since the new IDE code is not yet fully tested.
A few off things here...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
PDC20267: IDE controller at PCI slot 00:0b.0
PDC20267: chipset revision 2
PDC20267: not 100%% native mode: will probe irqs later
PDC20267: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.
ide2: BM-DMA at 0xb800-0xb807, BIOS settings: hde:DMA, hdf:DMA
ide3: BM-DMA at 0xb808-0xb80f, BIOS settings: hdg:pio, hdh:pio
VP_IDE: IDE controller at PCI slot 00:11.1
PCI: No IRQ known for interrupt pin A of device 00:11.1.
VP_IDE: chipset revision 6
VP_IDE: not 100%% native mode: will probe irqs later
VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
ide0: BM-DMA at 0xbc00-0xbc07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xbc08-0xbc0f, BIOS settings: hdc:DMA, hdd:DMA
hda: IC35L080AVVA07-0, ATA DISK drive
hdb: IC35L040AVER07-0, ATA DISK drive
hda: DMA disabled
^^^^^^^^^^^^^^^^^
What's up with this? For each drive in my system it claims it
has disabled DMA. But hdparm later reports that DMA is in fact
enabled. In fact, later on the kernel ever reports the drive
as being in UDMA 100 mode... I think these "DMA disabled"
messages are bogus.
blk: queue c03c4a00, I/O limit 4095Mb (mask 0xffffffff)
hdb: DMA disabled
^^^^^^^^^^^^^^^^^
blk: queue c03c4b4c, I/O limit 4095Mb (mask 0xffffffff)
hdc: PCRW804, ATAPI CD/DVD-ROM drive
hdd: Pioneer DVD-ROM ATAPIModel DVD-116 0122, ATAPI CD/DVD-ROM drive
hdc: DMA disabled
hdd: DMA disabled
^^^^^^^^^^^^^^^^^
hde: IC35L040AVER07-0, ATA DISK drive
hde: DMA disabled
^^^^^^^^^^^^^^^^^
Yet more bogus DMA disabled messages....
blk: queue c03c52d8, I/O limit 4095Mb (mask 0xffffffff)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
ide2 at 0x1800-0x1807,0xac02 on irq 11
hda: host protected area => 1
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
hda: 160836480 sectors (82348 MB) w/1863KiB Cache, CHS=10011/255/63, UDMA(100)
Now we see the funky "host protected area => 1" message. As
discussed earlier with Andre, this message should be removed from
the kernel. The message as written implies that the drive
actually has an active HPA -- which is not the case at all! All
this is doing is enumerating support for a particular drive
feature. Do we really care that the drive has Host Protected
Area feature set support? I don't care. I suppose it might be
interesting to note if there is actually an HPA in effect, but
this as is the message is just noise. If we are going to
enumerate drive capabilities, why not useful ones like the Power
Management feature set, or the Power-Up In Standby feature set...
I think we should kill the "host protected area => 1" message. If
people care about their drives supported feature set, they can
run 'hdparm -I' to find this out,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
^ permalink raw reply
* Re: hidden interface (ARP) 2.4.20
From: Bernd Eckenfels @ 2002-12-12 1:33 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <Pine.LNX.3.96.1021211110329.18520C-100000@gatekeeper.tmr.com>
In article <Pine.LNX.3.96.1021211110329.18520C-100000@gatekeeper.tmr.com> you wrote:
> Don't. You are right about this one, a client originated connection will
> have an ARP entry and route back by the original route.
Most likely it will not have an ARP entry, since there is only the ARP entry
for the router. Not-directly connected hosts are not listed in the
neighbours cache, but yes, you will have an routing cache entry (netstat
-C).
Greetings
Bernd
--
eckes privat - http://www.eckes.org/
Project Freefire - http://www.freefire.org/
^ permalink raw reply
* Re: terminal problems with escape characters
From: dashielljt @ 2002-12-12 1:11 UTC (permalink / raw)
To: Miguel González Castaños; +Cc: linux-admin
In-Reply-To: <3DF6FD58.F43F0801@tid.es>
I think the linux speakup site has a keymap editing tutorial but don't
know if it has the information in it you need.
Jude <dashielljt(at)gmpexpress-dot-net>
^ permalink raw reply
* Re: Client tuning
From: Andrew Ryan @ 2002-12-12 0:10 UTC (permalink / raw)
To: Jose Celestino; +Cc: nfs
Jose Celestino wrote:
>
> I have the option of choosing between NFSv2/v3 and TCP/UDP and the
> freedom to fully configure/reconfigure the client boxes. Any thoughs on
> what I might tweak and look for? Any experiences on this?
>
First off I would recommend subscribing to and staying subscribed to this
list. If you use linux NFS (as client and/or server) then this list will
be invaluable.
The UDP/TCP question should probably be in the FAQ, as it has come up
many times before on the list. If you have a mismatch
in network speeds (e.g. 1000BaseT on server and 100BaseT on client) TCP
will give you better speeds. However, UDP support has been more
historically reliable in the linux kernel, and more widely used.
I wouldn't recommend using TCP NFS client before 2.4.20, out of the box,
2.4.20 is stable for me so far.
You can try tweaking mount(8) parameters, kernel patches (applying various
patches from Trond's site, at http://www.fys.uio.no/~trondmy/src), and
even vendor kernel RPM's (most vendors include some subset of Trond's
patches).
But, mostly you will need to run tests with your own setup to determine
what is the most stable and best-performing combination of kernel and
mount parameters. And if you find bugs, report them to the list so they
can be fixed in future versions.
cheers,
andrew
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [PATCH] OSST tape driver fix for 2.5.51
From: Willem Riede @ 2002-12-12 1:05 UTC (permalink / raw)
To: linux-scsi
The patch to osst.c below is needed to fix an oops and at the same time
brings in some bug fixes discovered in the 2.4 version.
Thanks, Willem Riede.
--- /home/wriede/kernel/linux-2.5.51/drivers/scsi/osst.c Mon Dec 9 21:45:57 2002
+++ osst.c Wed Dec 11 19:37:12 2002
@@ -24,7 +24,7 @@
*/
static const char * cvsid = "$Id: osst.c,v 1.65 2001/11/11 20:38:56 riede Exp $";
-const char * osst_version = "0.99.0p3";
+const char * osst_version = "0.99.0p5";
/* The "failure to reconnect" firmware bug */
#define OSST_FW_NEED_POLL_MIN 10601 /*(107A)*/
@@ -60,7 +60,6 @@
in the drivers are more widely classified, this may be changed to KERN_DEBUG. */
#define OSST_DEB_MSG KERN_NOTICE
-
#include "scsi.h"
#include "hosts.h"
#include <scsi/scsi_ioctl.h>
@@ -85,7 +84,7 @@
MODULE_PARM_DESC(max_dev, "Maximum number of OnStream Tape Drives to attach (4)");
MODULE_PARM(write_threshold_kbs, "i");
-MODULE_PARM_DESC(write_threshold_kbs, "Asynchronous write threshold (KB; 30)");
+MODULE_PARM_DESC(write_threshold_kbs, "Asynchronous write threshold (KB; 32)");
MODULE_PARM(max_sg_segs, "i");
MODULE_PARM_DESC(max_sg_segs, "Maximum number of scatter/gather segments to use (9)");
@@ -170,8 +169,8 @@
.attach = osst_attach,
.detach = osst_detach,
.scsi_driverfs_driver = {
- .name = "osst",
- },
+ .name = "osst",
+ }
};
static int osst_int_ioctl(OS_Scsi_Tape *STp, Scsi_Request ** aSRpnt, unsigned int cmd_in,unsigned long arg);
@@ -221,7 +220,7 @@
if (scode) printk(OSST_DEB_MSG "%s:D: Sense: %02x, ASC: %02x, ASCQ: %02x\n",
name, scode, sense[12], sense[13]);
if (driver_byte(result) & DRIVER_SENSE)
- print_req_sense("osst", SRpnt);
+ print_req_sense("osst ", SRpnt);
}
// else
#endif
@@ -543,8 +542,6 @@
STp->first_frame_position);
goto err_out;
}
-// STp->frame_in_buffer = 1;
-
if (frame_seq_number != -1 && ntohl(aux->frame_seq_num) != frame_seq_number) {
if (!quiet)
#if DEBUG
@@ -749,7 +746,7 @@
Scsi_Request * SRpnt;
int result = 0;
- int delay = OSST_WAIT_LONG_WRITE_COMPLETE;
+ int delay = OSST_WAIT_WRITE_COMPLETE;
#if DEBUG
char *name = tape_name(STp);
@@ -763,17 +760,14 @@
SRpnt = osst_do_scsi(*aSRpnt, STp, cmd, 0, SCSI_DATA_NONE, STp->timeout, MAX_WRITE_RETRIES, TRUE);
*aSRpnt = SRpnt;
if (!SRpnt) return (-EBUSY);
-//printk(OSST_DEB_MSG "%s:X: Write filemark returned %x:%02x:%02x:%02x\n",dev,STp->buffer->syscall_result,SRpnt->sr_sense_buffer[2] & 0x0f,SRpnt->sr_sense_buffer[12],SRpnt->sr_sense_buffer[13]);
if (STp->buffer->syscall_result) {
if ((SRpnt->sr_sense_buffer[2] & 0x0f) == 2 && SRpnt->sr_sense_buffer[12] == 4) {
if (SRpnt->sr_sense_buffer[13] == 8) {
-//printk(OSST_DEB_MSG "%s:X: Long initial delay\n", dev);
delay = OSST_WAIT_LONG_WRITE_COMPLETE;
}
} else
result = osst_write_error_recovery(STp, aSRpnt, 0);
}
-//printk(OSST_DEB_MSG "%s:X: Entering wait ready (%d)\n",dev,delay);
result |= osst_wait_ready(STp, aSRpnt, 5 * 60, delay);
STp->ps[STp->partition].rw = OS_WRITING_COMPLETE;
@@ -1708,12 +1702,7 @@
name, last_mark_ppos);
return (-EIO);
}
- if (mt_op == MTBSFM) {
- STp->frame_seq_number++;
- STp->frame_in_buffer = 0;
- STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
- }
- return 0;
+ goto found;
}
#if DEBUG
printk(OSST_DEB_MSG "%s:D: Reverting to scan filemark backwards\n", name);
@@ -1741,10 +1730,13 @@
return (-EIO);
}
}
+found:
if (mt_op == MTBSFM) {
STp->frame_seq_number++;
- STp->frame_in_buffer = 0;
- STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
+ STp->frame_in_buffer = 0;
+ STp->buffer->buffer_bytes = 0;
+ STp->buffer->read_pointer = 0;
+ STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
}
return 0;
}
@@ -1797,8 +1789,10 @@
}
if (mt_op == MTFSF) {
STp->frame_seq_number++;
- STp->frame_in_buffer = 0;
- STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
+ STp->frame_in_buffer = 0;
+ STp->buffer->buffer_bytes = 0;
+ STp->buffer->read_pointer = 0;
+ STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
}
return 0;
}
@@ -1944,9 +1938,10 @@
}
if (mt_op == MTFSF) {
STp->frame_seq_number++;
- STp->frame_in_buffer = 0;
+ STp->frame_in_buffer = 0;
+ STp->buffer->buffer_bytes = 0;
STp->buffer->read_pointer = 0;
- STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
+ STp->logical_blk_num += ntohs(STp->buffer->aux->dat.dat_list[0].blk_cnt);
}
return 0;
}
@@ -3215,8 +3210,8 @@
/* Write must be integral number of blocks */
if (STp->block_size != 0 && (count % STp->block_size) != 0) {
- printk(KERN_ERR "%s:E: Write (%ld bytes) not multiple of tape block size (%d%c).\n",
- name, (unsigned long)count, STp->block_size<1024?
+ printk(KERN_ERR "%s:E: Write (%Zd bytes) not multiple of tape block size (%d%c).\n",
+ name, count, STp->block_size<1024?
STp->block_size:STp->block_size/1024, STp->block_size<1024?'b':'k');
retval = (-EINVAL);
goto out;
@@ -4140,8 +4135,14 @@
if (cmd_in == MTEOM)
STps->eof = ST_EOD;
- else if ((cmd_in == MTFSFM || cmd_in == MTBSF) && STps->eof == ST_FM_HIT)
- ioctl_result = osst_seek_logical_blk(STp, &SRpnt, STp->logical_blk_num - 1);
+ else if ((cmd_in == MTFSFM || cmd_in == MTBSF) && STps->eof == ST_FM_HIT) {
+ ioctl_result = osst_seek_logical_blk(STp, &SRpnt, STp->logical_blk_num-1);
+ STps->drv_block++;
+ STp->logical_blk_num++;
+ STp->frame_seq_number++;
+ STp->frame_in_buffer = 0;
+ STp->buffer->read_pointer = 0;
+ }
else if (cmd_in == MTFSF)
STps->eof = (STp->first_frame_position >= STp->eod_frame_ppos)?ST_EOD:ST_FM;
else if (chg_eof)
@@ -4233,8 +4234,7 @@
#endif
return (-EBUSY);
}
-
- if (!scsi_device_get(STp->device)) {
+ if (scsi_device_get(STp->device)) {
write_unlock(&os_scsi_tapes_lock);
#if DEBUG
printk(OSST_DEB_MSG "%s:D: Failed scsi_device_get.\n", name);
@@ -4856,12 +4856,6 @@
}
if (mtc.mt_op == MTSETPART) {
-/* if (!STp->can_partitions ||
- mtc.mt_count < 0 || mtc.mt_count >= ST_NBR_PARTITIONS)
- return (-EINVAL);
- if (mtc.mt_count >= STp->nbr_partitions &&
- (STp->nbr_partitions = nbr_partitions(inode)) < 0)
- return (-EIO);*/
if (mtc.mt_count >= STp->nbr_partitions)
retval = -EINVAL;
else {
@@ -4909,10 +4903,6 @@
goto out;
}
-/* if (STp->can_partitions && STp->ready == ST_READY &&
- (i = update_partition(inode)) < 0)
- {retval=i;goto out;}*/
-
if (mtc.mt_op == MTCOMPRESSION)
retval = -EINVAL /*osst_compression(STp, (mtc.mt_count & 1))*/;
else
@@ -4931,10 +4921,6 @@
goto out;
}
-/* if (STp->can_partitions &&
- (i = update_partition(inode)) < 0)
- {retval=i;goto out;}*/
-
if (cmd_type == _IOC_TYPE(MTIOCGET) && cmd_nr == _IOC_NR(MTIOCGET)) {
struct mtget mt_status;
@@ -5110,9 +5096,7 @@
for (segs=STbuffer->sg_segs=1, got=b_size;
segs < max_segs && got < OS_FRAME_SIZE; ) {
STbuffer->sg[segs].page =
- (OS_FRAME_SIZE - got <= PAGE_SIZE / 2) ?
- kmalloc(OS_FRAME_SIZE - got, priority):
- alloc_pages(priority, order);
+ alloc_pages(priority, (OS_FRAME_SIZE - got <= PAGE_SIZE) ? 0 : order);
STbuffer->sg[segs].offset = 0;
if (STbuffer->sg[segs].page == NULL) {
if (OS_FRAME_SIZE - got <= (max_segs - segs) * b_size / 2 && order) {
@@ -5320,10 +5304,8 @@
if (max_sg_segs >= OSST_FIRST_SG)
osst_max_sg_segs = max_sg_segs;
#if DEBUG
- printk(OSST_DEB_MSG "osst :D: max tapes %d, write threshold %d, s/g segs %d.\n",
+ printk(OSST_DEB_MSG "osst :D: max tapes %d, write threshold %d, max s/g segs %d.\n",
osst_max_dev, osst_write_threshold, osst_max_sg_segs);
-//printk(OSST_DEB_MSG "osst :D: sizeof(header) = %d (%s)\n",
-// sizeof(os_header_t),sizeof(os_header_t)==OS_DATA_SIZE?"ok":"error");
#endif
}
@@ -5446,7 +5428,7 @@
drive = alloc_disk(1);
if (!drive) {
printk(KERN_ERR "osst :E: Out of memory. Device not attached.\n");
- return 1;
+ goto out_slave_detach;
}
/* if this is the first attach, build the infrastructure */
@@ -5458,7 +5440,7 @@
if (os_scsi_tapes == NULL) {
write_unlock(&os_scsi_tapes_lock);
printk(KERN_ERR "osst :E: Unable to allocate array for OnStream SCSI tapes.\n");
- return 1;
+ goto out_put_disk;
}
for (i=0; i < osst_max_dev; ++i) os_scsi_tapes[i] = NULL;
}
@@ -5466,8 +5448,7 @@
if (osst_nr_dev >= osst_max_dev) {
write_unlock(&os_scsi_tapes_lock);
printk(KERN_ERR "osst :E: Too many tape devices (max. %d).\n", osst_max_dev);
- put_disk(drive);
- return 1;
+ goto out_put_disk;
}
/* find a free minor number */
@@ -5480,9 +5461,7 @@
if (tpnt == NULL) {
write_unlock(&os_scsi_tapes_lock);
printk(KERN_ERR "osst :E: Can't allocate device descriptor, device not attached.\n");
- put_disk(drive);
- scsi_slave_detach(SDp);
- return 1;
+ goto out_put_disk;
}
memset(tpnt, 0, sizeof(OS_Scsi_Tape));
@@ -5495,9 +5474,7 @@
write_unlock(&os_scsi_tapes_lock);
printk(KERN_ERR "osst :E: Unable to allocate a tape buffer, device not attached.\n");
kfree(tpnt);
- put_disk(drive);
- scsi_slave_detach(SDp);
- return 1;
+ goto out_put_disk;
}
os_scsi_tapes[dev_num] = tpnt;
tpnt->buffer = buffer;
@@ -5623,6 +5600,12 @@
SDp->model, SDp->host->host_no, SDp->channel, SDp->id, SDp->lun, tape_name(tpnt));
return 0;
+
+out_put_disk:
+ put_disk(drive);
+out_slave_detach:
+ scsi_slave_detach(SDp);
+ return 1;
};
static void osst_detach(Scsi_Device * SDp)
@@ -5630,48 +5613,46 @@
OS_Scsi_Tape * tpnt;
int i, mode;
+ if ((SDp->type != TYPE_TAPE) || (osst_nr_dev <= 0))
+ return;
+
write_lock(&os_scsi_tapes_lock);
- if (os_scsi_tapes != NULL) {
- for(i=0; i<osst_max_dev; i++) {
- tpnt = os_scsi_tapes[i];
- if(tpnt != NULL && tpnt->device == SDp) {
- tpnt->device = NULL;
- for (mode = 0; mode < ST_NBR_MODES; ++mode) {
- devfs_unregister (tpnt->de_r[mode]);
- tpnt->de_r[mode] = NULL;
- devfs_unregister (tpnt->de_n[mode]);
- tpnt->de_n[mode] = NULL;
- }
- devfs_unregister_tape(tpnt->drive->number);
- put_disk(tpnt->drive);
- os_scsi_tapes[i] = NULL;
- scsi_slave_detach(SDp);
- osst_nr_dev--;
- write_unlock(&os_scsi_tapes_lock);
- for (mode = 0; mode < ST_NBR_MODES; ++mode) {
- device_remove_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_type);
- device_remove_file(&tpnt->driverfs_dev_r[mode],
- &dev_attr_kdev);
- device_unregister(&tpnt->driverfs_dev_r[mode]);
- device_remove_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_type);
- device_remove_file(&tpnt->driverfs_dev_n[mode],
- &dev_attr_kdev);
- device_unregister(&tpnt->driverfs_dev_n[mode]);
- }
- if (tpnt->header_cache != NULL)
- vfree(tpnt->header_cache);
- if (tpnt->buffer) {
- normalize_buffer(tpnt->buffer);
- kfree(tpnt->buffer);
- }
- kfree(tpnt);
- break;
+ for(i=0; i < osst_max_dev; i++) {
+ if((tpnt = os_scsi_tapes[i]) && (tpnt->device == SDp)) {
+ tpnt->device = NULL;
+ for (mode = 0; mode < ST_NBR_MODES; ++mode) {
+ devfs_unregister (tpnt->de_r[mode]);
+ tpnt->de_r[mode] = NULL;
+ devfs_unregister (tpnt->de_n[mode]);
+ tpnt->de_n[mode] = NULL;
+ }
+ devfs_unregister_tape(tpnt->drive->number);
+ put_disk(tpnt->drive);
+ os_scsi_tapes[i] = NULL;
+ scsi_slave_detach(SDp);
+ osst_nr_dev--;
+ write_unlock(&os_scsi_tapes_lock);
+ for (mode = 0; mode < ST_NBR_MODES; ++mode) {
+ device_remove_file(&tpnt->driverfs_dev_r[mode],
+ &dev_attr_type);
+ device_remove_file(&tpnt->driverfs_dev_r[mode],
+ &dev_attr_kdev);
+ device_unregister(&tpnt->driverfs_dev_r[mode]);
+ device_remove_file(&tpnt->driverfs_dev_n[mode],
+ &dev_attr_type);
+ device_remove_file(&tpnt->driverfs_dev_n[mode],
+ &dev_attr_kdev);
+ device_unregister(&tpnt->driverfs_dev_n[mode]);
+ }
+ if (tpnt->header_cache != NULL) vfree(tpnt->header_cache);
+ if (tpnt->buffer) {
+ normalize_buffer(tpnt->buffer);
+ kfree(tpnt->buffer);
}
- }
+ kfree(tpnt);
+ return;
+ }
}
-
write_unlock(&os_scsi_tapes_lock);
return;
}
@@ -5681,12 +5662,8 @@
printk(KERN_INFO "osst :I: Tape driver with OnStream support version %s\nosst :I: %s\n", osst_version, cvsid);
validate_options();
-#if DEBUG
- printk(OSST_DEB_MSG "osst :D: %d s/g segments, write threshold %d bytes.\n",
- max_sg_segs, osst_write_threshold);
-#endif
- if ((register_chrdev(OSST_MAJOR, "osst", &osst_fops) < 0) ||
- scsi_register_device(&osst_template)) {
+
+ if ((register_chrdev(OSST_MAJOR,"osst", &osst_fops) < 0) || scsi_register_device(&osst_template)) {
printk(KERN_ERR "osst :E: Unable to register major %d for OnStream tapes\n", OSST_MAJOR);
return 1;
}
^ permalink raw reply
* Re: 2.5 Changes doc update.
From: Ian Wienand @ 2002-12-12 1:09 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20021211172559.GA8613@suse.de>
> Threading improvements.
> ~~~~~~~~~~~~~~~~~~~~~~~
> - Ingo Molnar put a lot of work into threading improvements during 2.5.
> Some of the features of this work are:
> - sys_clone() enhancements (CLONE_SETTLS, CLONE_SETTID, CLONE_CLEARTID,
> CLONE_DETACHED)
The middle two enhancements actually turned into three:
CLONE_PARENT_SETTID, CLONE_CHILD_SETTID and CLONE_CHILD_CLEARTID since
~2.5.47 or so, just for reference.
-i
ianw@gelato.unsw.edu.au
^ permalink raw reply
* orinoco_cs not working in 2.5.51
From: Thomas Molina @ 2002-12-12 0:56 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
After building 2.5.51 I am still unable to unable to load and configure
drivers for an eth0 wireless interface on my Presario 12XL325 laptop.
The
SMC2632W card works on all 2.4 kernels and 2.5 kernels through 2.5.47
as
previously documented in messages to this list. Nothing after 47 will
load and configure the eth0 device.
Mindful of the unsettled nature of module loading in latter 2.5
versions,
I do a build with modular components and a build with everything built
in.
Rusty Russell's latest module init tools work well with both 2.4 and 2.5
kernels, so I'm skeptical that module loading problems are the cause of
my
problem.
I've included a copy of my dmesg output, together with /proc/interrupts,
and /proc/ioports for the run in question. The output shows orinoco_cs
does a RequestIRQ and gets a resource in use messsage. Running the
dhclient program gives an eth0; no such device message.
[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 9972 bytes --]
Linux version 2.5.51-tm1 (tmolina@lap) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #1 Wed Dec 11 11:55:28 CST 2002
Video mode to be used for restore is 318
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000ea000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000077f0000 (usable)
BIOS-e820: 00000000077f0000 - 00000000077ffc00 (ACPI data)
BIOS-e820: 00000000077ffc00 - 0000000007800000 (ACPI NVS)
BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
119MB LOWMEM available.
On node 0 totalpages: 30704
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 26608 pages, LIFO batch:6
HighMem zone: 0 pages, LIFO batch:1
Building zonelist for node : 0
Kernel command line: ro root=/dev/hda5 vga=792 pci=usepirqmask
Initializing CPU#0
Detected 647.340 MHz processor.
Console: colour dummy device 80x25
Calibrating delay loop... 1265.66 BogoMIPS
Memory: 117444k/122816k available (2268k kernel code, 4820k reserved, 853k data, 140k init, 0k highmem)
Dentry cache hash table entries: 16384 (order: 5, 131072 bytes)
Inode-cache hash table entries: 8192 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
-> /dev
-> /dev/console
-> /root
CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000
CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000
CPU: Common caps: 0383f9ff 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
mtrr: v2.0 (20020519)
device class 'cpu': registering
device class cpu: adding driver system:cpu
PCI: PCI BIOS revision 2.10 entry at 0xfd83e, last bus=1
PCI: Using configuration type 1
device class cpu: adding device CPU 0
interfaces: adding device CPU 0
BIO: pool of 256 setup, 15Kb (60 bytes/bio)
biovec pool[0]: 1 bvecs: 228 entries (12 bytes)
biovec pool[1]: 4 bvecs: 228 entries (48 bytes)
biovec pool[2]: 16 bvecs: 228 entries (192 bytes)
biovec pool[3]: 64 bvecs: 228 entries (768 bytes)
biovec pool[4]: 128 bvecs: 114 entries (1536 bytes)
biovec pool[5]: 256 bvecs: 57 entries (3072 bytes)
block request queues:
128 requests per read queue
128 requests per write queue
8 requests per batch
enter congestion at 31
exit congestion at 33
drivers/usb/core/usb.c: registered new driver hub
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Address space collision on region 9 of bridge 00:07.4 [8080:808f]
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
aio_setup: sizeof(struct page) = 40
[c1176040] eventpoll: successfully initialized.
Journalled Block Device driver loaded
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Serial: 8250/16550 driver $Revision: 1.90 $ IRQ sharing disabled
parport0: PC-style at 0x378 (0x778) [PCSPP(,...)]
parport_pc: Via 686A parallel port: io=0x378
i2c-core.o: i2c core module version 2.6.4 (20020719)
i2c-dev.o: i2c /dev entries driver module version 2.6.4 (20020719)
i2c-algo-bit.o: i2c bit algorithm module version 2.6.4 (20020719)
i2c-philips-par.o: i2c Philips parallel port adapter module version 2.6.4 (20020719)
i2c-philips-par.o: attaching to parport0
i2c-dev.o: Registered 'Philips Parallel port adapter' as minor 0
i2c-elv.o: i2c ELV parallel port adapter module version 2.6.4 (20020719)
i2c-velleman.o: i2c Velleman K8000 adapter module version 2.6.4 (20020719)
i2c-velleman.o: Port 0x378 already in use.
i2c-algo-pcf.o: i2c pcf8584 algorithm module version 2.6.4 (20020719)
i2c-elektor.o: i2c pcf8584-isa adapter module version 2.6.4 (20020719)
i2c-proc.o version 2.6.4 (20020719)
vesafb: framebuffer at 0xf5000000, mapped to 0xc8000000, size 8192k
vesafb: mode is 1024x768x32, linelength=4096, pages=1
vesafb: protected mode interface info at c000:6812
vesafb: scrolling: redraw
vesafb: directcolor: size=0:8:8:8, shift=0:16:8:0
fb0: VESA VGA frame buffer device
Console: switching to colour frame buffer device 128x48
pty: 256 Unix98 ptys configured
parport0: no more devices allowed
lp: driver loaded but no devices found
Real Time Clock Driver v1.11
Linux agpgart interface v1.0 (c) Dave Jones
agpgart: Unsupported VIA chipset (device id: 0601), you might want to try agp_try_unsupported=1.
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
orinoco.c 0.13a (David Gibson <hermes@gibson.dropbear.id.au> and others)
hermes.c: 4 Jul 2002 David Gibson <hermes@gibson.dropbear.id.au>
orinoco_cs.c 0.13a (David Gibson <hermes@gibson.dropbear.id.au> and others)
orinoco_pci.c 0.13a (Jean Tourrilhes <jt@hpl.hp.com>)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 00:07.1
VP_IDE: chipset revision 16
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0x1420-0x1427, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0x1428-0x142f, BIOS settings: hdc:DMA, hdd:pio
hda: IBM-DJSA-220, ATA DISK drive
hda: DMA disabled
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: TOSHIBA DVD-ROM SD-C2402, ATAPI CD/DVD-ROM drive
hdc: DMA disabled
ide1 at 0x170-0x177,0x376 on irq 15
hda: host protected area => 1
hda: 39070080 sectors (20004 MB) w/1874KiB Cache, CHS=38760/16/63, UDMA(33)
hda: hda1 hda2 < hda5 hda6 >
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
end_request: I/O error, dev hdc, sector 0
Console: switching to colour frame buffer device 128x48
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
PCI: Assigned IRQ 9 for device 00:0a.0
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.0
PCI: Found IRQ 11 for device 00:07.2
uhci-hcd 00:07.2: VIA Technologies, In USB
uhci-hcd 00:07.2: irq 11, io base 00001400
drivers/usb/core/hcd.c: new USB bus registered, assigned bus number 1
Yenta IRQ list 0018, PCI irq9
Socket status: 30000010
drivers/usb/core/hub.c: USB hub found at 0
drivers/usb/core/hub.c: 2 ports detected
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
input: PS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
i2c-core.o: i2c core module version 2.6.4 (20020719)
i2c-dev.o: i2c /dev entries driver module version 2.6.4 (20020719)
scx200_acb: NatSemi SCx200 ACCESS.bus Driver
i2c-proc.o version 2.6.4 (20020719)
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
Advanced Linux Sound Architecture Driver Version 0.9.0rc5 (Sun Nov 10 19:48:18 2002 UTC).
no UART detected at 0xffff
ALSA sound/drivers/mtpav.c:592: MTVAP port 0x378 is busy
ALSA sound/drivers/mpu401/mpu401.c:68: specify port
PCI: Found IRQ 9 for device 00:07.5
PCI: Setting latency timer of device 00:07.5 to 64
ALSA device list:
#0: Dummy 1
#1: Virtual MIDI Card 1
#2: VIA 82C686A/B at 0x1000, irq 9
oprofile: using timer interrupt.
NET4: Linux TCP/IP 1.0 for NET4.0
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 8192 bind 16384)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 140k freed
EXT3 FS 2.4-0.9.16, 02 Dec 2001 on ide0(3,5), internal journal
Adding 113360k swap on /dev/hda6. Priority:-1 extents:1
cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcbfff 0xe0000-0xfffff
orinoco_cs: RequestIRQ: Resource in use
0000-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
03c0-03df : vesafb
03f6-03f6 : ide0
0cf8-0cff : PCI conf1
1000-10ff : VIA Technologies, In VT82C686 AC97 Audio
1000-10ff : VIA686A
1400-141f : VIA Technologies, In USB
1400-141f : uhci-hcd
1420-142f : VIA Technologies, In VT82C586B PIPC Bus M
1420-1427 : ide0
1428-142f : ide1
1430-1433 : VIA Technologies, In VT82C686 AC97 Audio
1434-1437 : VIA Technologies, In VT82C686 AC97 Audio
1438-143f : Conexant HSF 56k Data/Fax Mod
1800-18ff : PCI CardBus #02
1c00-1cff : PCI CardBus #02
8000-80ff : VIA Technologies, In VT82C686 [Apollo Sup
CPU0
0: 167131 XT-PIC timer
1: 409 XT-PIC i8042
2: 0 XT-PIC cascade
8: 1 XT-PIC rtc
9: 0 XT-PIC Texas Instruments PCI1410 PC card Card, VIA686A
11: 0 XT-PIC uhci-hcd
12: 27 XT-PIC i8042
14: 2722 XT-PIC ide0
15: 10 XT-PIC ide1
NMI: 0
ERR: 0
^ permalink raw reply
* Re: [PATCH 2.5] SGI O2 framebuffer driver
From: Alan Cox @ 2002-12-12 1:31 UTC (permalink / raw)
To: Vivien Chappelier; +Cc: Ralf Baechle, linux-mips, Ilya Volynets
In-Reply-To: <Pine.LNX.4.21.0212120004330.2300-100000@melkor>
On Wed, 2002-12-11 at 23:41, Vivien Chappelier wrote:
> linear framebuffer (up to 8MB with 64kB granularity). I'm then remapping
> all those pages to one virtual region obtained from get_vm_area so that
> 1. caching attributes can be set to cacheable write-through no WA
Ick. The framebuffer can't handle cached and write barriers ?
^ permalink raw reply
* Re: PATCH: Four function buttons on DELL Latitude X200
From: Andries Brouwer @ 2002-12-12 1:01 UTC (permalink / raw)
To: Pavel Machek; +Cc: H. Peter Anvin, linux-kernel
In-Reply-To: <20021210213444.GA451@elf.ucw.cz>
On Tue, Dec 10, 2002 at 10:34:44PM +0100, Pavel Machek wrote:
> > The PC only has so many possible keycodes (with E0 and E1 it's still
> > in the sub-300 range.) It won't fit within 128, but I would really
> > like an algorithmic mapping from scancodes to keycodes so we don't
> > continue to have this problem.
> >
> > For example, using a 16-bit keycode model:
> >
> >
> > Scancode Keycode (binary)
> > mxxxxxxx m0000000 0xxxxxxx
> > E0 mxxxxxxx m0000000 1xxxxxxx
> > E1 mxxxxxxx yyyyyyyy mxxxxxxx yyyyyyyy
> >
> > m = make/break bit
>
> Well, nothing prevents keyboard manufacturers from using 0xe2 as a
> prefix, too. I think there are really *weird* keyboards out there.
>
> Pavel
Indeed. See, for example,
http://www.win.tue.nl/~aeb/linux/kbd/scancodes-2.html#ss2.18
for a keyboard that uses 0x80 as a prefix.
^ permalink raw reply
* Re: HyperThreading in recent 2.4-ac kernels
From: Alan Cox @ 2002-12-12 1:36 UTC (permalink / raw)
To: Gerald Britton; +Cc: Alan Cox, Linux Kernel Mailing List
In-Reply-To: <20021211183059.A19030@light-brigade.mit.edu>
On Wed, 2002-12-11 at 23:30, Gerald Britton wrote:
> HyperThreading appears to work properly in vanilla 2.4.x, but fails to
> initialize the sibling CPUs in 2.4.x-ac. The problem appears to be in
> improper indexing by physical vs. logical CPU numbers.
Thanks. Can you verify 2.4.21-pre1 is ok. That has the latest and
greatest code in these areas and code -ac will drop its development
atuff for. If 2.4.21-pre1 works all is cool, if not it would be very
good to know early on
^ permalink raw reply
* Re: [TRIVIAL PATCH 2.5.51] Remove compile warning from drivers/ide/pci/cs5520.c
From: Alan Cox @ 2002-12-12 1:29 UTC (permalink / raw)
To: Bob Miller; +Cc: trivial, Linux Kernel Mailing List
In-Reply-To: <20021211222810.GA1067@doc.pdx.osdl.net>
On Wed, 2002-12-11 at 22:28, Bob Miller wrote:
> The function, cs5520_tune_chipset() is declared to return an int.
> Added a return statement instead of just falling of off the bottom.
>
> diff -Nru a/drivers/ide/pci/cs5520.c b/drivers/ide/pci/cs5520.c
> --- a/drivers/ide/pci/cs5520.c Wed Dec 11 13:41:51 2002
> +++ b/drivers/ide/pci/cs5520.c Wed Dec 11 13:41:51 2002
> @@ -166,6 +166,8 @@
> /* ATAPI is harder so leave it for now */
> if(!error && drive->media == ide_disk)
> error = hwif->ide_dma_on(drive);
> +
> + return error;
Eep thats a nasty little bug, lucky my compiler left the error value in
%eax anyway good spotting
^ permalink raw reply
* [patch/trvial^3] epoll bits forgot a nasty printk() ...
From: Davide Libenzi @ 2002-12-12 0:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robert Love, Linux Kernel Mailing List
Linus, Robert made me notice that I forgot an explicit debugging printk()
inside the epoll module.
o Make the printk() to be debugging
- Davide
diff -Nru linux-2.5.51.vanilla/fs/eventpoll.c linux-2.5.51.epoll/fs/eventpoll.c
--- linux-2.5.51.vanilla/fs/eventpoll.c Wed Dec 11 16:28:11 2002
+++ linux-2.5.51.epoll/fs/eventpoll.c Wed Dec 11 16:31:46 2002
@@ -1573,7 +1573,7 @@
if (IS_ERR(eventpoll_mnt))
goto eexit_4;
- printk(KERN_INFO "[%p] eventpoll: successfully initialized.\n", current);
+ DNPRINTK(3, (KERN_INFO "[%p] eventpoll: successfully initialized.\n", current));
return 0;
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Andrew Morton @ 2002-12-12 0:50 UTC (permalink / raw)
To: Rusty Russell
Cc: jt, Linux kernel mailing list, Benjamin Reed, Jeff Garzik,
dahinds
In-Reply-To: <20021212003733.2AF922C0E0@lists.samba.org>
Rusty Russell wrote:
>
> In message <20021211174305.GB11264@bougret.hpl.hp.com> you write:
> > On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> > > > o removal of airo_cs : "Uninitialised timer!/nThis is a
> > > > warning. Your computer is OK". Call trace on demand. Also, the module
> > > > airo not removed (probably due to problem with airo_cs).
> > >
> > > That, in itself, should be harmless.
> >
> > Yes, but this is new and I don't really like it. I suspect
> > something is wrong in the Pcmcia code itself. Last I tried was 2.5.46
> > and I see some suspicious init_timer() added where I would not expect,
> > and some missing where they would be needed.
> > Hum... Who is in charge ?
>
> Well, Andrew Morton made the change that required timers to be
> initialized, and the check which locates ones which are not. As to
> who is responsible for airo_cs, I'm guessing Ben Reed, as author.
wakes up.
> > I personally believe the timer thingy is important and cause
> > of problems.
>
> I disagree: the warning is supposed to silently fix it up.
>
yes. It goes like this:
1: The new super-scalable SMP timers code had a locking problem which
made 8-ways go oops.
2: The fix was to add a spinlock to struct timer_list.
3: spinlocks need to be initialised.
3a: struct timer_list needs to be initialised.
This is a problem, because it has traditionally been the case that
an all-zeroes struct timer_list is "initialised". That is no longer
the case. All timers must now be prepared with init_timer() or
TIMER_INITIALIZER()
So debugging code was added to the timer layer to detect when someone
passes an uninitialised timer into the core timer functions. That debug
code generates a warning, a backtrace and then initialises the timer
for you, so things run happily.
I did an audit and fixed up probably a hundred or so uninitialised timers,
but there will be a few leftovers.
The intent is that people will report these leftovers, they get fixed up
and then one day we pull out the debug code.
^ permalink raw reply
* Re: Compilation problems with local APIC for uniprocessors in linux 2.4.20-ac2
From: Alan Cox @ 2002-12-12 1:25 UTC (permalink / raw)
To: system_lists; +Cc: Linux Kernel Mailing List
In-Reply-To: <5.1.1.6.2.20021212002424.00cdeb00@192.168.2.131>
Thanks. Hopefully tha will go away in 21pre1-ac1 once I have the merge
done. Marcelo merged the final summit code so I can now back out a lot
of not quite final summit code and other cruft
^ permalink raw reply
* Re: Reliable hardware
From: Alan Cox @ 2002-12-12 1:24 UTC (permalink / raw)
To: Patrick Finnegan; +Cc: Orion Poplawski, scott, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212111834030.9201-100000@ibm-ps850.purdueriots.com>
On Wed, 2002-12-11 at 23:35, Patrick Finnegan wrote:
> Which chipset - the new or the old one? I've got an ASUS A7M266D (or
> something) that's based on the AMD 760MPX chipset and has 512MB of
> Registered ECC memory, and a pair of XP 1800+'s... and it works just
> beautifuly. Truely rock solid.
Same board you have.
^ permalink raw reply
* Re: Linux 2.5.51
From: Matthew Dobson @ 2002-12-12 0:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kernel Mailing List, William Lee Irwin III, Martin J. Bligh
In-Reply-To: <Pine.LNX.4.44.0212091912180.17200-100000@penguin.transmeta.com>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
Linus,
This patch (from wli & myself) was overlooked for 2.5.51. Without this
fix, sysfs panics when registering topology for NUMA boxen. Please add
this to your bk tree.
[mcd@arrakis push]$ diffstat topo_ordering-2.5.51.patch
memblk.c | 4 ++--
node.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
Cheers!
-Matt
[-- Attachment #2: topo_ordering-2.5.51.patch --]
[-- Type: text/plain, Size: 1160 bytes --]
diff -Nur --exclude-from=/usr/src/.dontdiff linux-2.5.51-vanilla/drivers/base/memblk.c linux-2.5.51-topo_ordering/drivers/base/memblk.c
--- linux-2.5.51-vanilla/drivers/base/memblk.c Mon Dec 9 18:46:26 2002
+++ linux-2.5.51-topo_ordering/drivers/base/memblk.c Wed Dec 11 16:36:31 2002
@@ -49,7 +49,7 @@
static int __init register_memblk_type(void)
{
- driver_register(&memblk_driver);
- return devclass_register(&memblk_devclass);
+ int error = devclass_register(&memblk_devclass);
+ return error ? error : driver_register(&memblk_driver);
}
postcore_initcall(register_memblk_type);
diff -Nur --exclude-from=/usr/src/.dontdiff linux-2.5.51-vanilla/drivers/base/node.c linux-2.5.51-topo_ordering/drivers/base/node.c
--- linux-2.5.51-vanilla/drivers/base/node.c Mon Dec 9 18:45:44 2002
+++ linux-2.5.51-topo_ordering/drivers/base/node.c Wed Dec 11 16:36:06 2002
@@ -93,7 +93,7 @@
static int __init register_node_type(void)
{
- devclass_register(&node_devclass);
- return driver_register(&node_driver);
+ int error = devclass_register(&node_devclass);
+ return error ? error : driver_register(&node_driver);
}
postcore_initcall(register_node_type);
^ permalink raw reply
* Re: capable open_port() check wrong for kmem
From: Chris Wright @ 2002-12-12 0:43 UTC (permalink / raw)
To: carbonated beverage; +Cc: linux-kernel
In-Reply-To: <20021210065159.GB17928@net-ronin.org>
* carbonated beverage (ramune@net-ronin.org) wrote:
>
> It's rather annoying and counter-intuitive to have:
>
> crw-r----- 1 root kmem 1, 2 Sep 8 21:56 /dev/kmem
>
> but to have the following code fragment give:
>
> int fd;
> fd = open("/dev/kmem", O_RDONLY);
> if(fd == -1) {
> fprintf(stderr, "Can't open /dev/kmem: %s\n", strerror(errno));
> exit(EXIT_FAILURE);
> }
>
> Can't open /dev/kmem: Operation not permitted
>
> with a user in the kmem group.
>
> Also, the utility I'm writing doesn't need write access, so why give it to
> the process in the first place?
Then open O_RDONLY (with CAP_SYS_RAWIO). Then the utility won't have
write access. If that's all you are worried about.
or.
If you have only one capability (CAP_SYS_RAWIO), you are not owner of
/dev/kmem, you are in group kmem, and /dev/kmem is 0640, then all you will
get is read-only access to /dev/kmem. This does not require kernel changes.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* RE: Slow SCSI AIC7xxx on 2.5.48
From: Shureih, Tariq @ 2002-12-12 0:40 UTC (permalink / raw)
To: Lmkl (linux-kernel@vger.kernel.org)
On other thing I forgot to mention. Uptime would show (after 30 or 40 secs
of waiting for it to return) that system load was > .80 even though no major
apps were running (no X or anything else).
--
Tariq Shureih
Intel Corporation
Opinions are my own and don't represent my emplyer
-----Original Message-----
From: Shureih, Tariq [mailto:tariq.shureih@intel.com]
Sent: Wednesday, December 11, 2002 4:03 PM
To: Lmkl (linux-kernel@vger.kernel.org)
Subject: Slow SCSI AIC7xxx on 2.5.48
Has anyone noticed some serious degradation in performance using AIC7xxx
driver in 2.5.48?
I have a system with Intel's SL2 dual PIII Xeon 933 with on board scsi
adaptec.
When I load the 2.4.19 kernel, everything is fine.
Using 2.5.48, when I login it takes it sometimes up to 1 minute 34 seconds
to return me a prompt and good luck with "ps".
No errors or messages though.
I have not tried it with 2.5.51 to see if anything changed.
Is this known?
*_*_*_*_*_*
Tariq Shureih
*_*_*_*_*_*_*_*_*
Opinions are my own and don't represent my employer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: 2.5.51 modprobe bttv hangs
From: Rusty Russell @ 2002-12-12 0:37 UTC (permalink / raw)
To: Kees Bakker; +Cc: linux-kernel
In-Reply-To: <15863.42680.271592.252350@iris.hendrikweg.doorn>
In message <15863.42680.271592.252350@iris.hendrikweg.doorn> you write:
> With 2.5.50 and 2.5.51 I get a hanging modprobe if I try to load
> bttv. I get all the normal messages from the modules, bt878 and
> others, while it loads the modules. But then it hangs. Unfortunately I
> haven't got much else to show you. The program does not want to terminate
> with ^C. And also an lsmod while this happens is also going to hang.
>
> I'm using module-init-tools-0.9.3. What do I do to get more debug output?
Hi Kees,
Thanks for the report. Looks like bttv does a request module
from its init function. Please try the following fix and report back.
Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Name: Module init reentry fix
Author: Rusty Russell
Status: Tested on 2.5.51
D: This changes the code to drop the module_mutex() before calling the
D: module's init function, so module init functions can call
D: request_module(). This was trivial before someone broke the module
D: code to start non-live. Now it requires us to keep info on the
D: exact module state.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .27854-linux-2.5.51/include/linux/module.h .27854-linux-2.5.51.updated/include/linux/module.h
--- .27854-linux-2.5.51/include/linux/module.h 2002-12-10 15:56:53.000000000 +1100
+++ .27854-linux-2.5.51.updated/include/linux/module.h 2002-12-12 11:31:28.000000000 +1100
@@ -116,10 +116,16 @@ struct module_ref
atomic_t count;
} ____cacheline_aligned;
+enum module_state
+{
+ MODULE_STATE_LIVE,
+ MODULE_STATE_COMING,
+ MODULE_STATE_GOING,
+};
+
struct module
{
- /* Am I live (yet)? */
- int live;
+ enum module_state state;
/* Member of list of modules */
struct list_head list;
@@ -177,6 +183,14 @@ struct module
char args[0];
};
+/* FIXME: It'd be nice to isolate modules during init, too, so they
+ aren't used before they (may) fail. But presently too much code
+ (IDE & SCSI) require entry into the module during init.*/
+static inline int module_is_live(struct module *mod)
+{
+ return mod->state != MODULE_STATE_GOING;
+}
+
#ifdef CONFIG_MODULE_UNLOAD
void __symbol_put(const char *symbol);
@@ -195,7 +209,7 @@ static inline int try_module_get(struct
if (module) {
unsigned int cpu = get_cpu();
- if (likely(module->live))
+ if (likely(module_is_live(module)))
local_inc(&module->ref[cpu].count);
else
ret = 0;
@@ -210,7 +224,7 @@ static inline void module_put(struct mod
unsigned int cpu = get_cpu();
local_dec(&module->ref[cpu].count);
/* Maybe they're waiting for us to drop reference? */
- if (unlikely(!module->live))
+ if (unlikely(!module_is_live(module)))
wake_up_process(module->waiter);
put_cpu();
}
@@ -219,7 +233,7 @@ static inline void module_put(struct mod
#else /*!CONFIG_MODULE_UNLOAD*/
static inline int try_module_get(struct module *module)
{
- return !module || module->live;
+ return !module || module_is_live(module);
}
static inline void module_put(struct module *module)
{
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .27854-linux-2.5.51/kernel/module.c .27854-linux-2.5.51.updated/kernel/module.c
--- .27854-linux-2.5.51/kernel/module.c 2002-12-10 15:56:54.000000000 +1100
+++ .27854-linux-2.5.51.updated/kernel/module.c 2002-12-12 11:31:28.000000000 +1100
@@ -44,6 +44,14 @@
static DECLARE_MUTEX(module_mutex);
LIST_HEAD(modules); /* FIXME: Accessed w/o lock on oops by some archs */
+/* We require a truly strong try_module_get() */
+static inline int strong_try_module_get(struct module *mod)
+{
+ if (mod && mod->state == MODULE_STATE_COMING)
+ return 0;
+ return try_module_get(mod);
+}
+
/* Convenient structure for holding init and core sizes */
struct sizes
{
@@ -378,7 +386,7 @@ sys_delete_module(const char *name_user,
}
/* Already dying? */
- if (!mod->live) {
+ if (mod->state == MODULE_STATE_GOING) {
/* FIXME: if (force), slam module count and wake up
waiter --RR */
DEBUGP("%s already dying\n", mod->name);
@@ -386,6 +394,16 @@ sys_delete_module(const char *name_user,
goto out;
}
+ /* Coming up? Allow force on stuck modules. */
+ if (mod->state == MODULE_STATE_COMING) {
+ forced = try_force(flags);
+ if (!forced) {
+ /* This module can't be removed */
+ ret = -EBUSY;
+ goto out;
+ }
+ }
+
if (!mod->exit || mod->unsafe) {
forced = try_force(flags);
if (!forced) {
@@ -407,7 +425,7 @@ sys_delete_module(const char *name_user,
ret = -EWOULDBLOCK;
} else {
mod->waiter = current;
- mod->live = 0;
+ mod->state = MODULE_STATE_GOING;
}
restart_refcounts();
@@ -507,7 +525,7 @@ static inline void module_unload_free(st
static inline int use_module(struct module *a, struct module *b)
{
- return try_module_get(b);
+ return strong_try_module_get(b);
}
static inline void module_unload_init(struct module *mod)
@@ -578,7 +596,7 @@ void *__symbol_get(const char *symbol)
spin_lock_irqsave(&modlist_lock, flags);
value = __find_symbol(symbol, &ksg);
- if (value && !try_module_get(ksg->owner))
+ if (value && !strong_try_module_get(ksg->owner))
value = 0;
spin_unlock_irqrestore(&modlist_lock, flags);
@@ -935,12 +953,8 @@ static struct module *load_module(void *
goto free_mod;
}
- /* Initialize the lists, since they will be list_del'd if init fails */
- INIT_LIST_HEAD(&mod->extable.list);
- INIT_LIST_HEAD(&mod->list);
- INIT_LIST_HEAD(&mod->symbols.list);
mod->symbols.owner = mod;
- mod->live = 0;
+ mod->state = MODULE_STATE_COMING;
module_unload_init(mod);
/* How much space will we need? (Common area in first) */
@@ -1097,51 +1111,40 @@ sys_init_module(void *umod,
flush_icache_range((unsigned long)mod->module_core,
(unsigned long)mod->module_core + mod->core_size);
- /* Now sew it into exception list (just in case...). */
+ /* Now sew it into the lists. They won't access us, since
+ strong_try_module_get() will fail. */
spin_lock_irq(&modlist_lock);
list_add(&mod->extable.list, &extables);
+ list_add_tail(&mod->symbols.list, &symbols);
spin_unlock_irq(&modlist_lock);
+ list_add(&mod->list, &modules);
+
+ /* Drop lock so they can recurse */
+ up(&module_mutex);
- /* Note, setting the mod->live to 1 here is safe because we haven't
- * linked the module into the system's kernel symbol table yet,
- * which means that the only way any other kernel code can call
- * into this module right now is if this module hands out entry
- * pointers to the other code. We assume that no module hands out
- * entry pointers to the rest of the kernel unless it is ready to
- * have them used.
- */
- mod->live = 1;
/* Start the module */
ret = mod->init ? mod->init() : 0;
if (ret < 0) {
/* Init routine failed: abort. Try to protect us from
buggy refcounters. */
+ mod->state = MODULE_STATE_GOING;
synchronize_kernel();
- if (mod->unsafe) {
+ if (mod->unsafe)
printk(KERN_ERR "%s: module is now stuck!\n",
mod->name);
- /* Mark it "live" so that they can force
- deletion later, and we don't keep getting
- woken on every decrement. */
- } else {
- mod->live = 0;
+ else {
+ down(&module_mutex);
free_module(mod);
+ up(&module_mutex);
}
- up(&module_mutex);
return ret;
}
/* Now it's a first class citizen! */
- spin_lock_irq(&modlist_lock);
- list_add_tail(&mod->symbols.list, &symbols);
- spin_unlock_irq(&modlist_lock);
- list_add(&mod->list, &modules);
-
+ mod->state = MODULE_STATE_LIVE;
module_free(mod, mod->module_init);
mod->module_init = NULL;
- /* All ok! */
- up(&module_mutex);
return 0;
}
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Rusty Russell @ 2002-12-11 22:41 UTC (permalink / raw)
To: Jeff Garzik; +Cc: jt, Linux kernel mailing list, Jeff Garzik, dahinds, davem
In-Reply-To: <20021211174036.GA2612@gtf.org>
In message <20021211174036.GA2612@gtf.org> you write:
> On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> > idra-usb.c: add "netdev->owner = THIS_MODULE;" and get rid of the
> > MOD_INC_USE_COUNT.
>
> Incorrect but close: one uses SET_MODULE_OWNER(netdev) for this.
BTW, what *is* the purpose of that macro, other than obfuscation?
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Rusty Russell @ 2002-12-11 22:46 UTC (permalink / raw)
To: jt; +Cc: Linux kernel mailing list, Benjamin Reed, Jeff Garzik, dahinds
In-Reply-To: <20021211174305.GB11264@bougret.hpl.hp.com>
In message <20021211174305.GB11264@bougret.hpl.hp.com> you write:
> On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty Russell wrote:
> > > o removal of airo_cs : "Uninitialised timer!/nThis is a
> > > warning. Your computer is OK". Call trace on demand. Also, the module
> > > airo not removed (probably due to problem with airo_cs).
> >
> > That, in itself, should be harmless.
>
> Yes, but this is new and I don't really like it. I suspect
> something is wrong in the Pcmcia code itself. Last I tried was 2.5.46
> and I see some suspicious init_timer() added where I would not expect,
> and some missing where they would be needed.
> Hum... Who is in charge ?
Well, Andrew Morton made the change that required timers to be
initialized, and the check which locates ones which are not. As to
who is responsible for airo_cs, I'm guessing Ben Reed, as author.
> I personally believe the timer thingy is important and cause
> of problems.
I disagree: the warning is supposed to silently fix it up.
> Thanks a lot !
>
> Jean
That's what I'm here for,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
^ permalink raw reply
* RE: Strange load spikes on 2.4.19 kernel
From: Steven Roussey @ 2002-12-12 0:31 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
In-Reply-To: <3DF7D4A9.C93316D8@digeo.com>
> Looks like all your apache instances woke up and started doing something.
> What makes you think it's a kernel or ext3 thing?
Google. ;) My search led to this particular thread, but I could not find a
final determination. I did just get a message from Rob saying that his
problem was a simultaneous wakeup as well:
http://groups.google.com/groups?q=strange+load+spikes+solved&hl=en&lr=&ie=UT
F-8&oe=UTF-8&selm=06fa01c294cc%24bcf46e10%241900a8c0%40lifebook&rnum=1
I'll move this to an apache list. Thank you for your time. I know it is
limited.
Sincerely,
Steven Roussey
http://Network54.com/
^ permalink raw reply
* Re: Memory Measurements and Lots of Files and Inodes
From: Andrew Morton @ 2002-12-12 0:27 UTC (permalink / raw)
To: Patrick R. McManus; +Cc: linux-kernel
In-Reply-To: <20021212002110.GA27532@ducksong.com>
"Patrick R. McManus" wrote:
>
> ...
> > If you could share your test apps that would help a lot.
>
> sure! this is the "lots of files" program.
Yep, negative dentries:
dentry_cache: 149092KB 149092KB 100.0
ext3_inode_cache: 3425KB 10102KB 33.90
radix_tree_node: 594KB 1612KB 36.88
buffer_head: 543KB 1264KB 42.99
You can monitor these via /proc/slabinfo, or using Bill's bloatmeter
script from http://www.zip.com.au/~akpm/linux/patches/stuff/
> ...
>
> > On your machine it'll be "all of swap plus all of physical memory
> > minus whatever malloc'ed memory you're using now minus 8-12 megabytes".
> > There isn't much memory which cannot be reclaimed unless you have a
> > huge machine or you're doing odd things.
>
> this is useful advice, thanks. Basically what the new procps does?
I don't know what procps does.
But your fill-up-all-memory program will certainly do the trick.
Run it, create a huge swapstorm (or get oom-killed if there's no
swap) and then see what `free' says. That's as much memory as the
kernel will ever give you.
^ permalink raw reply
* Re: problems with ALSA
From: r4mz3z @ 2002-12-12 0:19 UTC (permalink / raw)
To: dashielljt, linux-newbie
In-Reply-To: <Pine.LNX.4.50.0212112042140.4071-100000@athame.gmpexpress.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi...
I know which is my card, I'm using a VIA card:
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233 AC97 Audio
Controller (rev 40)
Subsystem: C-Media Electronics Inc: Unknown device 0300
Flags: medium devsel, IRQ 3
I/O ports at e000 [size=256]
Capabilities: [c0] Power Management version 2
And compile ALSA with the option snd-via82xx, the files exist and everything
look fine, but when I use modprobe... It doesn't works.
Please help me
thanks
El Jue 12 Dic 2002 01:46, dashielljt escribió:
> Have you tried: lspci -v >lspci.log <cr> then had a look inside of
> lspci.log to see if you could find your sound card? If it's a p&P sound
> card only this won't work, but if it's in a pci slot it's possible lspci
> -v can give you the vendor and type of card which may be enough to get
> alsa going correctly. That should also provide you port info, but even
> before that perhaps dmesg >dmesg.log as root and reading down that file to
> see if the system even finds a sound card would be useful.
>
> Jude <dashielljt(at)gmpexpress-dot-net>
- --
Linux User Registered #232544
my GnuPG-key at www.keyserver.net
--- rm -rf /bin/laden ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE999YLs4dF9gl05swRAhgDAJ9NBcRDQIVCsLxlFChZYIf1HR006wCfVtnE
3NZ2iy6rHOhQg0CgYlpWRTk=
=DkH/
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* problems with dmesg
From: r4mz3z @ 2002-12-12 0:15 UTC (permalink / raw)
To: linux-newbie
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi friends..
I'm using RedHat 7.3 and when I try to run "dmesg" receive this message:
no more MTRRs available
mtrr: no more MTRRs available
mtrr: no more MTRRs available
...
...
thanks 4 your help
- --
Linux User Registered #232544
my GnuPG-key at www.keyserver.net
--- rm -rf /bin/laden ---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE999U1s4dF9gl05swRAkkjAJ45YenaXpR86dbARBaVIHKyYrnDOACeIcQ2
6EWDzNt4xt1X62qRuY+pMhA=
=S4sM
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.