* RE: MIPS64 status?
From: Jason Gunthorpe @ 2002-01-14 23:59 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mips
In-Reply-To: <NEBBLJGMNKKEEMNLHGAICENCCEAA.mdharm@momenco.com>
On Mon, 14 Jan 2002, Matthew Dharm wrote:
> Does this mean we could map PCI memory/IO addresses above 4G and have
> it work?
Ooh, don't go there :> We looked at that and actually did it then backed
it out.
The PCI spec (particuarly PCI-X) tries to make it possible, but in a
general system with PCI sockets/etc it is just is not feasible. PCI
bridges need to be located below 4G, as do the majority of devices made.
There is also a performance hit for having device registers > 4G.
You'd definately need the mips64 kernel to do that, or use ugly wired TLB
entries with normal mips.
Jason
^ permalink raw reply
* [PATCH] 2.5.2-pre11: drivers/ide/ide-tape.c
From: Frank Davis @ 2002-01-15 0:47 UTC (permalink / raw)
To: linux-kernel; +Cc: fdavis
Hello all,
I have attached a patch for drivers/ide/ide-tape.c against
2.5.2-pre10/11 . It includes the following:
dev_t --> kdev_t changes
buffer_head --> bio updates.
Please review. Thanks.
Regards,
Frank
--- drivers/ide/ide-tape.c.old Tue Jan 8 21:15:54 2002
+++ drivers/ide/ide-tape.c Tue Jan 8 21:15:45 2002
@@ -721,7 +721,7 @@
int request_transfer; /* Bytes to transfer */
int actually_transferred; /* Bytes actually transferred */
int buffer_size; /* Size of our data buffer */
- struct buffer_head *bh;
+ struct bio *bio;
char *b_data;
int b_count;
byte *buffer; /* Data buffer */
@@ -805,7 +805,7 @@
*/
typedef struct idetape_stage_s {
struct request rq; /* The corresponding request */
- struct buffer_head *bh; /* The data buffers */
+ struct bio *bio; /* The data buffers */
struct idetape_stage_s *next; /* Pointer to the next stage */
os_aux_t *aux; /* OnStream aux ptr */
} idetape_stage_t;
@@ -929,7 +929,7 @@
int stage_size; /* Data buffer size (chosen based on the tape's recommendation */
idetape_stage_t *merge_stage;
int merge_stage_size;
- struct buffer_head *bh;
+ struct bio *bio;
char *b_data;
int b_count;
@@ -1013,7 +1013,7 @@
* Measures number of frames:
*
* 1. written/read to/from the driver pipeline (pipeline_head).
- * 2. written/read to/from the tape buffers (buffer_head).
+ * 2. written/read to/from the tape buffers (bio).
* 3. written/read by the tape to/from the media (tape_head).
*/
int pipeline_head;
@@ -1493,52 +1493,52 @@
static void idetape_input_buffers (ide_drive_t *drive, idetape_pc_t *pc, unsigned int bcount)
{
- struct buffer_head *bh = pc->bh;
+ struct bio *bio = pc->bio;
int count;
while (bcount) {
#if IDETAPE_DEBUG_BUGS
- if (bh == NULL) {
- printk (KERN_ERR "ide-tape: bh == NULL in idetape_input_buffers\n");
+ if (bio == NULL) {
+ printk (KERN_ERR "ide-tape: bio == NULL in idetape_input_buffers\n");
idetape_discard_data (drive, bcount);
return;
}
#endif /* IDETAPE_DEBUG_BUGS */
- count = IDE_MIN (bh->b_size - atomic_read(&bh->b_count), bcount);
- atapi_input_bytes (drive, bh->b_data + atomic_read(&bh->b_count), count);
+ count = IDE_MIN (bio->bi_size - pc->b_count, bcount);
+ atapi_input_bytes (drive, bio_data(bio) + pc->b_count, count);
bcount -= count;
- atomic_add(count, &bh->b_count);
- if (atomic_read(&bh->b_count) == bh->b_size) {
- bh = bh->b_reqnext;
- if (bh)
- atomic_set(&bh->b_count, 0);
+ pc->b_count += bio->bi_size;
+ if (pc->b_count == bio->bi_size) {
+ bio = bio->bi_next;
+ if (bio)
+ pc->b_count = 0;
}
}
- pc->bh = bh;
+ pc->bio = bio;
}
static void idetape_output_buffers (ide_drive_t *drive, idetape_pc_t *pc, unsigned int bcount)
{
- struct buffer_head *bh = pc->bh;
+ struct bio *bio = pc->bio;
int count;
while (bcount) {
#if IDETAPE_DEBUG_BUGS
- if (bh == NULL) {
- printk (KERN_ERR "ide-tape: bh == NULL in idetape_output_buffers\n");
+ if (bio == NULL) {
+ printk (KERN_ERR "ide-tape: bio == NULL in idetape_output_buffers\n");
return;
}
#endif /* IDETAPE_DEBUG_BUGS */
count = IDE_MIN (pc->b_count, bcount);
- atapi_output_bytes (drive, pc->b_data, count);
+ atapi_output_bytes (drive, bio_data(bio), count);
bcount -= count;
pc->b_data += count;
pc->b_count -= count;
if (!pc->b_count) {
- pc->bh = bh = bh->b_reqnext;
- if (bh) {
- pc->b_data = bh->b_data;
- pc->b_count = atomic_read(&bh->b_count);
+ pc->bio = bio = bio->bi_next;
+ if (bio) {
+ pc->b_data = bio_data(bio);
+ pc->b_count = bio->bi_size;
}
}
}
@@ -1547,25 +1547,25 @@
#ifdef CONFIG_BLK_DEV_IDEDMA
static void idetape_update_buffers (idetape_pc_t *pc)
{
- struct buffer_head *bh = pc->bh;
+ struct bio *bio = pc->bio;
int count, bcount = pc->actually_transferred;
if (test_bit (PC_WRITING, &pc->flags))
return;
while (bcount) {
#if IDETAPE_DEBUG_BUGS
- if (bh == NULL) {
- printk (KERN_ERR "ide-tape: bh == NULL in idetape_update_buffers\n");
+ if (bio == NULL) {
+ printk (KERN_ERR "ide-tape: bio == NULL in idetape_update_buffers\n");
return;
}
#endif /* IDETAPE_DEBUG_BUGS */
- count = IDE_MIN (bh->b_size, bcount);
- atomic_set(&bh->b_count, count);
- if (atomic_read(&bh->b_count) == bh->b_size)
- bh = bh->b_reqnext;
+ count = IDE_MIN (bio->bi_size, bcount);
+ pc->b_count = count;
+ if (pc->b_count == bio->bi_size)
+ bio = bio->bi_next;
bcount -= count;
}
- pc->bh = bh;
+ pc->bio = bio;
}
#endif /* CONFIG_BLK_DEV_IDEDMA */
@@ -1625,7 +1625,7 @@
pc->request_transfer = 0;
pc->buffer = pc->pc_buffer;
pc->buffer_size = IDETAPE_PC_BUFFER_SIZE;
- pc->bh = NULL;
+ pc->bio = NULL;
pc->b_data = NULL;
}
@@ -1706,10 +1706,10 @@
printk(KERN_INFO "ide-tape: %s: idetape_abort_pipeline called\n", tape->name);
#endif
while (stage) {
- if (stage->rq.cmd == IDETAPE_WRITE_RQ)
- stage->rq.cmd = IDETAPE_ABORTED_WRITE_RQ;
- else if (stage->rq.cmd == IDETAPE_READ_RQ)
- stage->rq.cmd = IDETAPE_ABORTED_READ_RQ;
+ if (stage->rq.flags == IDETAPE_WRITE_RQ)
+ stage->rq.flags = IDETAPE_ABORTED_WRITE_RQ;
+ else if (stage->rq.flags == IDETAPE_READ_RQ)
+ stage->rq.flags = IDETAPE_ABORTED_READ_RQ;
stage = stage->next;
}
}
@@ -1735,7 +1735,7 @@
#endif /* IDETAPE_DEBUG_BUGS */
rq->buffer = NULL;
- rq->bh = stage->bh;
+ rq->bio = stage->bio;
tape->active_data_request = rq;
tape->active_stage = stage;
tape->next_stage = stage->next;
@@ -1769,21 +1769,21 @@
*/
static void __idetape_kfree_stage (idetape_stage_t *stage)
{
- struct buffer_head *prev_bh, *bh = stage->bh;
+ struct bio *prev_bio, *bio = stage->bio;
int size;
- while (bh != NULL) {
- if (bh->b_data != NULL) {
- size = (int) bh->b_size;
+ while (bio != NULL) {
+ if (bio_data(bio) != NULL) {
+ size = (int) bio->bi_size;
while (size > 0) {
- free_page ((unsigned long) bh->b_data);
+ free_page ((unsigned long) bio_data(bio));
size -= PAGE_SIZE;
- bh->b_data += PAGE_SIZE;
+ bio->bi_size += PAGE_SIZE;
}
}
- prev_bh = bh;
- bh = bh->b_reqnext;
- kfree (prev_bh);
+ prev_bio = bio;
+ bio = bio->bi_next;
+ kfree (prev_bio);
}
kfree (stage);
}
@@ -1868,13 +1868,13 @@
tape->active_stage = NULL;
tape->active_data_request = NULL;
tape->nr_pending_stages--;
- if (rq->cmd == IDETAPE_WRITE_RQ) {
+ if (rq->flags == IDETAPE_WRITE_RQ) {
#if ONSTREAM_DEBUG
if (tape->debug_level >= 2) {
if (tape->onstream) {
stage = tape->first_stage;
aux = stage->aux;
- p = stage->bh->b_data;
+ p = bio_data(stage->bio);
if (ntohl(aux->logical_blk_num) < 11300 && ntohl(aux->logical_blk_num) > 11100)
printk(KERN_INFO "ide-tape: finished writing logical blk %u (data %x %x %x %x)\n", ntohl(aux->logical_blk_num), *p++, *p++, *p++, *p++);
}
@@ -1908,7 +1908,7 @@
complete(tape->waiting);
}
}
- } else if (rq->cmd == IDETAPE_READ_RQ) {
+ } else if (rq->flags == IDETAPE_READ_RQ) {
if (error == IDETAPE_ERROR_EOD) {
set_bit (IDETAPE_PIPELINE_ERROR, &tape->flags);
idetape_abort_pipeline(drive);
@@ -1984,7 +1984,7 @@
{
ide_init_drive_cmd (rq);
rq->buffer = (char *) pc;
- rq->cmd = IDETAPE_PC_RQ1;
+ rq->flags = IDETAPE_PC_RQ1;
(void) ide_do_drive_cmd (drive, rq, ide_preempt);
}
@@ -2164,12 +2164,12 @@
}
}
if (test_bit (PC_WRITING, &pc->flags)) {
- if (pc->bh != NULL)
+ if (pc->bio != NULL)
idetape_output_buffers (drive, pc, bcount.all);
else
atapi_output_bytes (drive,pc->current_position,bcount.all); /* Write the current buffer */
} else {
- if (pc->bh != NULL)
+ if (pc->bio != NULL)
idetape_input_buffers (drive, pc, bcount.all);
else
atapi_input_bytes (drive,pc->current_position,bcount.all); /* Read the current buffer */
@@ -2523,21 +2523,22 @@
return ide_stopped;
}
-static void idetape_create_read_cmd (idetape_tape_t *tape, idetape_pc_t *pc, unsigned int length, struct buffer_head *bh)
+static void idetape_create_read_cmd (idetape_tape_t *tape, idetape_pc_t *pc, unsigned int length, struct bio *bio)
{
- struct buffer_head *p = bh;
+ struct bio *p = bio;
+ struct bio_vec *bv = bio_iovec(p);
idetape_init_pc (pc);
pc->c[0] = IDETAPE_READ_CMD;
put_unaligned (htonl (length), (unsigned int *) &pc->c[1]);
pc->c[1] = 1;
pc->callback = &idetape_rw_callback;
- pc->bh = bh;
- atomic_set(&bh->b_count, 0);
+ pc->bio = bio;
+ bv->bv_len = 0;
pc->buffer = NULL;
if (tape->onstream) {
while (p) {
- atomic_set(&p->b_count, 0);
- p = p->b_reqnext;
+ bv->bv_len = 0;
+ p = p->bi_next;
}
}
if (!tape->onstream) {
@@ -2553,30 +2554,31 @@
}
}
-static void idetape_create_read_buffer_cmd(idetape_tape_t *tape, idetape_pc_t *pc, unsigned int length, struct buffer_head *bh)
+static void idetape_create_read_buffer_cmd(idetape_tape_t *tape, idetape_pc_t *pc, unsigned int length, struct bio *bio)
{
int size = 32768;
- struct buffer_head *p = bh;
+ struct bio *p = bio;
idetape_init_pc (pc);
pc->c[0] = IDETAPE_READ_BUFFER_CMD;
pc->c[1] = IDETAPE_RETRIEVE_FAULTY_BLOCK;
pc->c[7] = size >> 8;
pc->c[8] = size & 0xff;
pc->callback = &idetape_pc_callback;
- pc->bh = bh;
- atomic_set(&bh->b_count, 0);
+ pc->bio = bio;
+ atomic_set(&bio->bi_cnt, 0);
pc->buffer = NULL;
while (p) {
- atomic_set(&p->b_count, 0);
- p = p->b_reqnext;
+ p->bi_size = 0;
+ p = p->bi_next;
}
pc->request_transfer = pc->buffer_size = size;
}
-static void idetape_create_write_cmd (idetape_tape_t *tape, idetape_pc_t *pc, unsigned int length, struct buffer_head *bh)
+static void idetape_create_write_cmd (idetape_tape_t *tape, idetape_pc_t *pc, unsigned int length, struct bio *bio)
{
- struct buffer_head *p = bh;
+ struct bio *p = bio;
+ struct bio_vec *bv= bio_iovec(p);
idetape_init_pc (pc);
pc->c[0] = IDETAPE_WRITE_CMD;
put_unaligned (htonl (length), (unsigned int *) &pc->c[1]);
@@ -2585,13 +2587,13 @@
set_bit (PC_WRITING, &pc->flags);
if (tape->onstream) {
while (p) {
- atomic_set(&p->b_count, p->b_size);
- p = p->b_reqnext;
+ bv->bv_len = p->bi_size;
+ p = p->bi_next;
}
}
- pc->bh = bh;
- pc->b_data = bh->b_data;
- pc->b_count = atomic_read(&bh->b_count);
+ pc->bio = bio;
+ pc->b_data = bio_data(bio);
+ pc->b_count = bio->bi_size;
pc->buffer = NULL;
if (!tape->onstream) {
pc->request_transfer = pc->buffer_size = length * tape->tape_block_size;
@@ -2618,16 +2620,16 @@
#if IDETAPE_DEBUG_LOG
if (tape->debug_level >= 5)
- printk (KERN_INFO "ide-tape: rq_status: %d, rq_dev: %u, cmd: %d, errors: %d\n",rq->rq_status,(unsigned int) rq->rq_dev,rq->cmd,rq->errors);
+/* printk (KERN_INFO "ide-tape: rq_status: %d, rq_dev: %u, cmd: %ld, errors: %d\n",rq->rq_status,(unsigned int) rq->rq_dev,rq->flags,rq->errors); */
if (tape->debug_level >= 2)
- printk (KERN_INFO "ide-tape: sector: %ld, nr_sectors: %ld, current_nr_sectors: %ld\n",rq->sector,rq->nr_sectors,rq->current_nr_sectors);
+ printk (KERN_INFO "ide-tape: sector: %ld, nr_sectors: %ld, current_nr_sectors: %d\n",rq->sector,rq->nr_sectors,rq->current_nr_sectors);
#endif /* IDETAPE_DEBUG_LOG */
- if (!IDETAPE_RQ_CMD (rq->cmd)) {
+ if (!IDETAPE_RQ_CMD (rq->flags)) {
/*
* We do not support buffer cache originated requests.
*/
- printk (KERN_NOTICE "ide-tape: %s: Unsupported command in request queue (%d)\n", drive->name, rq->cmd);
+ printk (KERN_NOTICE "ide-tape: %s: Unsupported command in request queue (%ld)\n", drive->name, rq->flags);
ide_end_request (0, HWGROUP (drive)); /* Let the common code handle it */
return ide_stopped;
}
@@ -2661,7 +2663,7 @@
*/
if (tape->onstream)
status.b.dsc = 1;
- if (!drive->dsc_overlap && rq->cmd != IDETAPE_PC_RQ2)
+ if (!drive->dsc_overlap && rq->flags != IDETAPE_PC_RQ2)
set_bit (IDETAPE_IGNORE_DSC, &tape->flags);
/*
@@ -2674,7 +2676,7 @@
*/
if (tape->tape_still_time > 100 && tape->tape_still_time < 200)
tape->measure_insert_time = 1;
- if (tape->req_buffer_fill && (rq->cmd == IDETAPE_WRITE_RQ || rq->cmd == IDETAPE_READ_RQ)) {
+ if (tape->req_buffer_fill && (rq->flags == IDETAPE_WRITE_RQ || rq->flags == IDETAPE_READ_RQ)) {
tape->req_buffer_fill = 0;
tape->writes_since_buffer_fill = 0;
tape->reads_since_buffer_fill = 0;
@@ -2688,19 +2690,19 @@
tape->insert_speed = tape->insert_size / 1024 * HZ / (jiffies - tape->insert_time);
calculate_speeds(drive);
if (tape->onstream && tape->max_frames &&
- ((rq->cmd == IDETAPE_WRITE_RQ &&
+ ((rq->flags == IDETAPE_WRITE_RQ &&
( tape->cur_frames == tape->max_frames ||
( tape->speed_control && tape->cur_frames > 5 &&
(tape->insert_speed > tape->max_insert_speed ||
(0 /* tape->cur_frames > 30 && tape->tape_still_time > 200 */) ) ) ) ) ||
- (rq->cmd == IDETAPE_READ_RQ &&
+ (rq->flags == IDETAPE_READ_RQ &&
( tape->cur_frames == 0 ||
( tape->speed_control && (tape->cur_frames < tape->max_frames - 5) &&
tape->insert_speed > tape->max_insert_speed ) ) && rq->nr_sectors) ) ) {
#if IDETAPE_DEBUG_LOG
if (tape->debug_level >= 4)
- printk(KERN_INFO "ide-tape: postponing request, cmd %d, cur %d, max %d\n",
- rq->cmd, tape->cur_frames, tape->max_frames);
+ printk(KERN_INFO "ide-tape: postponing request, cmd %ld, cur %d, max %d\n",
+ rq->flags, tape->cur_frames, tape->max_frames);
#endif
if (tape->postpone_cnt++ < 500) {
status.b.dsc = 0;
@@ -2718,7 +2720,7 @@
tape->dsc_timeout = jiffies + IDETAPE_DSC_RW_TIMEOUT;
} else if ((signed long) (jiffies - tape->dsc_timeout) > 0) {
printk (KERN_ERR "ide-tape: %s: DSC timeout\n", tape->name);
- if (rq->cmd == IDETAPE_PC_RQ2) {
+ if (rq->flags == IDETAPE_PC_RQ2) {
idetape_media_access_finished (drive);
return ide_stopped;
} else {
@@ -2729,7 +2731,7 @@
idetape_postpone_request (drive);
return ide_stopped;
}
- switch (rq->cmd) {
+ switch (rq->flags) {
case IDETAPE_READ_RQ:
tape->buffer_head++;
#if USE_IOTRACE
@@ -2744,7 +2746,7 @@
tape->req_buffer_fill = 1;
}
pc = idetape_next_pc_storage (drive);
- idetape_create_read_cmd (tape, pc, rq->current_nr_sectors, rq->bh);
+ idetape_create_read_cmd (tape, pc, rq->current_nr_sectors, rq->bio);
break;
case IDETAPE_WRITE_RQ:
tape->buffer_head++;
@@ -2761,15 +2763,15 @@
calculate_speeds(drive);
}
pc = idetape_next_pc_storage (drive);
- idetape_create_write_cmd (tape, pc, rq->current_nr_sectors, rq->bh);
+ idetape_create_write_cmd (tape, pc, rq->current_nr_sectors, rq->bio);
break;
case IDETAPE_READ_BUFFER_RQ:
tape->postpone_cnt = 0;
pc = idetape_next_pc_storage (drive);
- idetape_create_read_buffer_cmd (tape, pc, rq->current_nr_sectors, rq->bh);
+ idetape_create_read_buffer_cmd (tape, pc, rq->current_nr_sectors, rq->bio);
break;
case IDETAPE_ABORTED_WRITE_RQ:
- rq->cmd = IDETAPE_WRITE_RQ;
+ rq->flags = IDETAPE_WRITE_RQ;
idetape_end_request (IDETAPE_ERROR_EOD, HWGROUP(drive));
return ide_stopped;
case IDETAPE_ABORTED_READ_RQ:
@@ -2777,12 +2779,12 @@
if (tape->debug_level >= 2)
printk(KERN_INFO "ide-tape: %s: detected aborted read rq\n", tape->name);
#endif
- rq->cmd = IDETAPE_READ_RQ;
+ rq->flags = IDETAPE_READ_RQ;
idetape_end_request (IDETAPE_ERROR_EOD, HWGROUP(drive));
return ide_stopped;
case IDETAPE_PC_RQ1:
pc = (idetape_pc_t *) rq->buffer;
- rq->cmd = IDETAPE_PC_RQ2;
+ rq->flags = IDETAPE_PC_RQ2;
break;
case IDETAPE_PC_RQ2:
idetape_media_access_finished (drive);
@@ -2822,61 +2824,65 @@
static idetape_stage_t *__idetape_kmalloc_stage (idetape_tape_t *tape, int full, int clear)
{
idetape_stage_t *stage;
- struct buffer_head *prev_bh, *bh;
+ struct bio *prev_bio, *bio;
int pages = tape->pages_per_stage;
- char *b_data;
+ char *b_data = NULL;
+ struct bio_vec *bv;
if ((stage = (idetape_stage_t *) kmalloc (sizeof (idetape_stage_t),GFP_KERNEL)) == NULL)
return NULL;
stage->next = NULL;
- bh = stage->bh = (struct buffer_head *) kmalloc (sizeof (struct buffer_head), GFP_KERNEL);
- if (bh == NULL)
+ bio = stage->bio = bio_alloc(GFP_KERNEL,1);
+ bv = bio_iovec(bio);
+ bv->bv_len = 0;
+ if (bio == NULL)
goto abort;
- bh->b_reqnext = NULL;
- if ((bh->b_data = (char *) __get_free_page (GFP_KERNEL)) == NULL)
+ bio->bi_next = NULL;
+ if ((bio->bi_io_vec[0].bv_page = alloc_page(GFP_KERNEL)) == NULL)
goto abort;
if (clear)
- memset(bh->b_data, 0, PAGE_SIZE);
- bh->b_size = PAGE_SIZE;
- atomic_set(&bh->b_count, full ? bh->b_size : 0);
- set_bit (BH_Lock, &bh->b_state);
+ memset(bio_data(bio), 0, PAGE_SIZE);
+ bio->bi_size = PAGE_SIZE;
+ if(bv->bv_len == full) bv->bv_len = bio->bi_size;
+ set_bit (BH_Lock, &bio->bi_flags);
while (--pages) {
- if ((b_data = (char *) __get_free_page (GFP_KERNEL)) == NULL)
+ if ((bio->bi_io_vec[pages].bv_page = alloc_page(GFP_KERNEL)) == NULL)
goto abort;
if (clear)
- memset(b_data, 0, PAGE_SIZE);
- if (bh->b_data == b_data + PAGE_SIZE) {
- bh->b_size += PAGE_SIZE;
- bh->b_data -= PAGE_SIZE;
+ memset(bio_data(bio), 0, PAGE_SIZE);
+ if (bio->bi_size == bv->bv_len + PAGE_SIZE) {
+ bio->bi_size += PAGE_SIZE;
+ bv->bv_len += PAGE_SIZE;
+ bv->bv_offset -= PAGE_SIZE;
if (full)
- atomic_add(PAGE_SIZE, &bh->b_count);
+ bio->bi_size += PAGE_SIZE;
continue;
}
- if (b_data == bh->b_data + bh->b_size) {
- bh->b_size += PAGE_SIZE;
+ if (b_data == bio_data(bio) + bio->bi_size) {
+ bio->bi_size += PAGE_SIZE;
if (full)
- atomic_add(PAGE_SIZE, &bh->b_count);
+ bio->bi_size += PAGE_SIZE;
continue;
}
- prev_bh = bh;
- if ((bh = (struct buffer_head *) kmalloc (sizeof (struct buffer_head), GFP_KERNEL)) == NULL) {
- free_page ((unsigned long) b_data);
+ prev_bio = bio;
+ if ((bio = bio_alloc(GFP_KERNEL,1)) == NULL) {
+ free_page ((unsigned long) bio_data(bio));
goto abort;
}
- bh->b_reqnext = NULL;
- bh->b_data = b_data;
- bh->b_size = PAGE_SIZE;
- atomic_set(&bh->b_count, full ? bh->b_size : 0);
- set_bit (BH_Lock, &bh->b_state);
- prev_bh->b_reqnext = bh;
+ bio->bi_next = NULL;
+ //bio->bi_io_vec[0].bv_offset = b_data;
+ bio->bi_size = PAGE_SIZE;
+ atomic_set(&bio->bi_cnt, full ? bio->bi_size : 0);
+ set_bit (BH_Lock, &bio->bi_flags);
+ prev_bio->bi_next = bio;
}
- bh->b_size -= tape->excess_bh_size;
+ bio->bi_size -= tape->excess_bh_size;
if (full)
- atomic_sub(tape->excess_bh_size, &bh->b_count);
+ atomic_sub(tape->excess_bh_size, &bio->bi_cnt);
if (tape->onstream)
- stage->aux = (os_aux_t *) (bh->b_data + bh->b_size - OS_AUX_SIZE);
+ stage->aux = (os_aux_t *) (bio_data(bio) + bio->bi_size - OS_AUX_SIZE);
return stage;
abort:
__idetape_kfree_stage (stage);
@@ -2903,39 +2909,39 @@
static void idetape_copy_stage_from_user (idetape_tape_t *tape, idetape_stage_t *stage, const char *buf, int n)
{
- struct buffer_head *bh = tape->bh;
+ struct bio *bio = tape->bio;
int count;
while (n) {
#if IDETAPE_DEBUG_BUGS
- if (bh == NULL) {
- printk (KERN_ERR "ide-tape: bh == NULL in idetape_copy_stage_from_user\n");
+ if (bio == NULL) {
+ printk (KERN_ERR "ide-tape: bio == NULL in idetape_copy_stage_from_user\n");
return;
}
#endif /* IDETAPE_DEBUG_BUGS */
- count = IDE_MIN (bh->b_size - atomic_read(&bh->b_count), n);
- copy_from_user (bh->b_data + atomic_read(&bh->b_count), buf, count);
+ count = IDE_MIN (bio->bi_size - tape->b_count, n);
+ copy_from_user (bio_data(bio) + tape->b_count, buf, count);
n -= count;
- atomic_add(count, &bh->b_count);
+ bio->bi_size += count;
buf += count;
- if (atomic_read(&bh->b_count) == bh->b_size) {
- bh = bh->b_reqnext;
- if (bh)
- atomic_set(&bh->b_count, 0);
+ if (tape->b_count == bio->bi_size) {
+ bio = bio->bi_next;
+ if (bio)
+ tape->b_count = 0;
}
}
- tape->bh = bh;
+ tape->bio = bio;
}
static void idetape_copy_stage_to_user (idetape_tape_t *tape, char *buf, idetape_stage_t *stage, int n)
{
- struct buffer_head *bh = tape->bh;
+ struct bio *bio = tape->bio;
int count;
while (n) {
#if IDETAPE_DEBUG_BUGS
- if (bh == NULL) {
- printk (KERN_ERR "ide-tape: bh == NULL in idetape_copy_stage_to_user\n");
+ if (bio == NULL) {
+ printk (KERN_ERR "ide-tape: bio == NULL in idetape_copy_stage_to_user\n");
return;
}
#endif /* IDETAPE_DEBUG_BUGS */
@@ -2946,10 +2952,10 @@
tape->b_count -= count;
buf += count;
if (!tape->b_count) {
- tape->bh = bh = bh->b_reqnext;
- if (bh) {
- tape->b_data = bh->b_data;
- tape->b_count = atomic_read(&bh->b_count);
+ tape->bio = bio = bio->bi_next;
+ if (bio) {
+ tape->b_data = bio_data(bio);
+ tape->b_count = bio->bi_size;
}
}
}
@@ -2957,25 +2963,25 @@
static void idetape_init_merge_stage (idetape_tape_t *tape)
{
- struct buffer_head *bh = tape->merge_stage->bh;
+ struct bio *bio = tape->merge_stage->bio;
- tape->bh = bh;
+ tape->bio = bio;
if (tape->chrdev_direction == idetape_direction_write)
- atomic_set(&bh->b_count, 0);
+ atomic_set(&bio->bi_cnt, 0);
else {
- tape->b_data = bh->b_data;
- tape->b_count = atomic_read(&bh->b_count);
+ tape->b_data = bio_data(bio);
+ tape->b_count = atomic_read(&bio->bi_cnt);
}
}
static void idetape_switch_buffers (idetape_tape_t *tape, idetape_stage_t *stage)
{
- struct buffer_head *tmp;
+ struct bio *tmp;
os_aux_t *tmp_aux;
- tmp = stage->bh; tmp_aux = stage->aux;
- stage->bh = tape->merge_stage->bh; stage->aux = tape->merge_stage->aux;
- tape->merge_stage->bh = tmp; tape->merge_stage->aux = tmp_aux;
+ tmp = stage->bio; tmp_aux = stage->aux;
+ stage->bio = tape->merge_stage->bio; stage->aux = tape->merge_stage->aux;
+ tape->merge_stage->bio = tmp; tape->merge_stage->aux = tmp_aux;
idetape_init_merge_stage (tape);
}
@@ -3077,7 +3083,7 @@
idetape_tape_t *tape = drive->driver_data;
#if IDETAPE_DEBUG_BUGS
- if (rq == NULL || !IDETAPE_RQ_CMD (rq->cmd)) {
+ if (rq == NULL || !IDETAPE_RQ_CMD (rq->flags)) {
printk (KERN_ERR "ide-tape: bug: Trying to sleep on non-valid request\n");
return;
}
@@ -3185,7 +3191,7 @@
ide_init_drive_cmd (&rq);
rq.buffer = (char *) pc;
- rq.cmd = IDETAPE_PC_RQ1;
+ rq.flags = IDETAPE_PC_RQ1;
return ide_do_drive_cmd (drive, &rq, ide_wait);
}
@@ -3430,7 +3436,7 @@
* idetape_queue_rw_tail generates a read/write request for the block
* device interface and wait for it to be serviced.
*/
-static int idetape_queue_rw_tail (ide_drive_t *drive, int cmd, int blocks, struct buffer_head *bh)
+static int idetape_queue_rw_tail (ide_drive_t *drive, int cmd, int blocks, struct bio *bio)
{
idetape_tape_t *tape = drive->driver_data;
struct request rq;
@@ -3447,8 +3453,8 @@
#endif /* IDETAPE_DEBUG_BUGS */
ide_init_drive_cmd (&rq);
- rq.bh = bh;
- rq.cmd = cmd;
+ rq.bio = bio;
+ rq.flags = cmd;
rq.sector = tape->first_frame_position;
rq.nr_sectors = rq.current_nr_sectors = blocks;
if (tape->onstream)
@@ -3489,15 +3495,15 @@
if (!first)
first = stage;
aux = stage->aux;
- p = stage->bh->b_data;
- idetape_queue_rw_tail(drive, IDETAPE_READ_BUFFER_RQ, tape->capabilities.ctl, stage->bh);
+ p = bio_data(stage->bio);
+ idetape_queue_rw_tail(drive, IDETAPE_READ_BUFFER_RQ, tape->capabilities.ctl, stage->bio);
#if ONSTREAM_DEBUG
if (tape->debug_level >= 2)
printk(KERN_INFO "ide-tape: %s: read back logical block %d, data %x %x %x %x\n", tape->name, logical_blk_num, *p++, *p++, *p++, *p++);
#endif
rq = &stage->rq;
ide_init_drive_cmd (rq);
- rq->cmd = IDETAPE_WRITE_RQ;
+ rq->flags = IDETAPE_WRITE_RQ;
rq->sector = tape->first_frame_position;
rq->nr_sectors = rq->current_nr_sectors = tape->capabilities.ctl;
idetape_init_stage(drive, stage, OS_FRAME_TYPE_DATA, logical_blk_num++);
@@ -3646,18 +3652,18 @@
os_aux_t *aux = stage->aux;
os_partition_t *par = &aux->partition;
struct request *rq = &stage->rq;
- struct buffer_head *bh;
+ struct bio *bio;
if (!tape->onstream)
return 1;
if (tape->raw) {
if (rq->errors) {
- bh = stage->bh;
- while (bh) {
- memset(bh->b_data, 0, bh->b_size);
- bh = bh->b_reqnext;
+ bio = stage->bio;
+ while (bio) {
+ memset(bio_data(bio), 0, bio->bi_size);
+ bio = bio->bi_next;
}
- strcpy(stage->bh->b_data, "READ ERROR ON FRAME");
+ strcpy(bio_data(stage->bio), "READ ERROR ON FRAME");
}
return 1;
}
@@ -3767,12 +3773,12 @@
* Linux is short on memory. Fallback to
* non-pipelined operation mode for this request.
*/
- return idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, blocks, tape->merge_stage->bh);
+ return idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, blocks, tape->merge_stage->bio);
}
}
rq = &new_stage->rq;
ide_init_drive_cmd (rq);
- rq->cmd = IDETAPE_WRITE_RQ;
+ rq->flags = IDETAPE_WRITE_RQ;
rq->sector = tape->first_frame_position; /* Doesn't actually matter - We always assume sequential access */
rq->nr_sectors = rq->current_nr_sectors = blocks;
@@ -3843,7 +3849,7 @@
{
idetape_tape_t *tape = drive->driver_data;
int blocks, i, min;
- struct buffer_head *bh;
+ struct bio *bio;
#if IDETAPE_DEBUG_BUGS
if (tape->chrdev_direction != idetape_direction_write) {
@@ -3860,22 +3866,22 @@
if (tape->merge_stage_size % tape->tape_block_size) {
blocks++;
i = tape->tape_block_size - tape->merge_stage_size % tape->tape_block_size;
- bh = tape->bh->b_reqnext;
- while (bh) {
- atomic_set(&bh->b_count, 0);
- bh = bh->b_reqnext;
+ bio = tape->bio->bi_next;
+ while (bio) {
+ atomic_set(&bio->bi_cnt, 0);
+ bio = bio->bi_next;
}
- bh = tape->bh;
+ bio = tape->bio;
while (i) {
- if (bh == NULL) {
- printk(KERN_INFO "ide-tape: bug, bh NULL\n");
+ if (bio == NULL) {
+ printk(KERN_INFO "ide-tape: bug, bio NULL\n");
break;
}
- min = IDE_MIN(i, bh->b_size - atomic_read(&bh->b_count));
- memset(bh->b_data + atomic_read(&bh->b_count), 0, min);
- atomic_add(min, &bh->b_count);
+ min = IDE_MIN(i, bio->bi_size - atomic_read(&bio->bi_cnt));
+ memset(bio_data(bio) + bio->bi_size, 0, min);
+ atomic_add(min, &bio->bi_cnt);
i -= min;
- bh = bh->b_reqnext;
+ bio = bio->bi_next;
}
}
(void) idetape_add_chrdev_write_request (drive, blocks);
@@ -3949,7 +3955,7 @@
* is switched from completion mode to buffer available
* mode.
*/
- bytes_read = idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, 0, tape->merge_stage->bh);
+ bytes_read = idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, 0, tape->merge_stage->bio);
if (bytes_read < 0) {
kfree (tape->merge_stage);
tape->merge_stage = NULL;
@@ -3960,7 +3966,7 @@
if (tape->restart_speed_control_req)
idetape_restart_speed_control(drive);
ide_init_drive_cmd (&rq);
- rq.cmd = IDETAPE_READ_RQ;
+ rq.flags = IDETAPE_READ_RQ;
rq.sector = tape->first_frame_position;
rq.nr_sectors = rq.current_nr_sectors = blocks;
if (!test_bit(IDETAPE_PIPELINE_ERROR, &tape->flags) && tape->nr_stages <= max_stages) {
@@ -4083,7 +4089,7 @@
}
if (test_bit(IDETAPE_PIPELINE_ERROR, &tape->flags))
return 0;
- return idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, blocks, tape->merge_stage->bh);
+ return idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, blocks, tape->merge_stage->bio);
}
rq_ptr = &tape->first_stage->rq;
bytes_read = tape->tape_block_size * (rq_ptr->nr_sectors - rq_ptr->current_nr_sectors);
@@ -4137,21 +4143,21 @@
static void idetape_pad_zeros (ide_drive_t *drive, int bcount)
{
idetape_tape_t *tape = drive->driver_data;
- struct buffer_head *bh;
+ struct bio *bio;
int count, blocks;
while (bcount) {
- bh = tape->merge_stage->bh;
+ bio = tape->merge_stage->bio;
count = IDE_MIN (tape->stage_size, bcount);
bcount -= count;
blocks = count / tape->tape_block_size;
while (count) {
- atomic_set(&bh->b_count, IDE_MIN (count, bh->b_size));
- memset (bh->b_data, 0, atomic_read(&bh->b_count));
- count -= atomic_read(&bh->b_count);
- bh = bh->b_reqnext;
+ atomic_set(&bio->bi_cnt, IDE_MIN (count, bio->bi_size));
+ memset (bio_data(bio), 0, bio->bi_size);
+ count -= atomic_read(&bio->bi_cnt);
+ bio = bio->bi_next;
}
- idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, blocks, tape->merge_stage->bh);
+ idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, blocks, tape->merge_stage->bio);
}
}
@@ -4276,7 +4282,7 @@
*/
static ide_drive_t *get_drive_ptr (kdev_t i_rdev)
{
- unsigned int i = MINOR(i_rdev) & ~0xc0;
+ unsigned int i = minor(i_rdev) & ~0xc0;
if (i >= MAX_HWIFS * MAX_DRIVES)
return NULL;
@@ -4654,7 +4660,7 @@
printk(KERN_INFO "ide-tape: current position (2) tape block %d\n", tape->last_frame_position);
#endif
idetape_position_tape(drive, last_mark_addr, 0, 0);
- if (!idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, 1, stage->bh)) {
+ if (!idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, 1, stage->bio)) {
printk(KERN_INFO "ide-tape: %s: couldn't read last marker\n", tape->name);
__idetape_kfree_stage (stage);
idetape_position_tape(drive, position, 0, 0);
@@ -4673,7 +4679,7 @@
#endif
aux->next_mark_addr = htonl(next_mark_addr);
idetape_position_tape(drive, last_mark_addr, 0, 0);
- if (!idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 1, stage->bh)) {
+ if (!idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 1, stage->bio)) {
printk(KERN_INFO "ide-tape: %s: couldn't write back marker frame at %d\n", tape->name, last_mark_addr);
__idetape_kfree_stage (stage);
idetape_position_tape(drive, position, 0, 0);
@@ -4705,9 +4711,9 @@
if (rc != 0)
return; /* don't write fillers if we cannot position the tape. */
- strcpy(stage->bh->b_data, "Filler");
+ strcpy(bio_data(stage->bio), "Filler");
while (cnt--) {
- if (!idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 1, stage->bh)) {
+ if (!idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 1, stage->bio)) {
printk(KERN_INFO "ide-tape: %s: write_filler: couldn't write header frame\n", tape->name);
__idetape_kfree_stage (stage);
return;
@@ -4739,9 +4745,9 @@
header.partition.last_frame_addr = htonl(tape->capacity);
header.partition.wrt_pass_cntr = htons(tape->wrt_pass_cntr);
header.partition.eod_frame_addr = htonl(tape->eod_frame_addr);
- memcpy(stage->bh->b_data, &header, sizeof(header));
+ memcpy(bio_data(stage->bio), &header, sizeof(header));
while (cnt--) {
- if (!idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 1, stage->bh)) {
+ if (!idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 1, stage->bio)) {
printk(KERN_INFO "ide-tape: %s: couldn't write header frame\n", tape->name);
__idetape_kfree_stage (stage);
return;
@@ -4860,7 +4866,7 @@
* is switched from completion mode to buffer available
* mode.
*/
- retval = idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 0, tape->merge_stage->bh);
+ retval = idetape_queue_rw_tail (drive, IDETAPE_WRITE_RQ, 0, tape->merge_stage->bio);
if (retval < 0) {
kfree (tape->merge_stage);
tape->merge_stage = NULL;
@@ -5326,12 +5332,12 @@
printk(KERN_INFO "ide-tape: %s: reading header\n", tape->name);
#endif
idetape_position_tape(drive, block, 0, 0);
- if (!idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, 1, stage->bh)) {
+ if (!idetape_queue_rw_tail (drive, IDETAPE_READ_RQ, 1, stage->bio)) {
printk(KERN_INFO "ide-tape: %s: couldn't read header frame\n", tape->name);
__idetape_kfree_stage (stage);
return 0;
}
- header = (os_header_t *) stage->bh->b_data;
+ header = (os_header_t *) bio_data(stage->bio);
aux = stage->aux;
if (strncmp(header->ident_str, "ADR_SEQ", 7) != 0) {
printk(KERN_INFO "ide-tape: %s: invalid header identification string\n", tape->name);
@@ -5403,7 +5409,7 @@
ide_drive_t *drive;
idetape_tape_t *tape;
idetape_pc_t pc;
- unsigned int minor=MINOR (inode->i_rdev);
+ unsigned int minor=minor(inode->i_rdev);
#if IDETAPE_DEBUG_LOG
printk (KERN_INFO "ide-tape: Reached idetape_chrdev_open\n");
@@ -5460,7 +5466,7 @@
{
ide_drive_t *drive = get_drive_ptr (inode->i_rdev);
idetape_tape_t *tape = drive->driver_data;
- unsigned int minor=MINOR (inode->i_rdev);
+ unsigned int minor=minor(inode->i_rdev);
idetape_empty_write_pipeline (drive);
tape->merge_stage = __idetape_kmalloc_stage (tape, 1, 0);
@@ -5486,7 +5492,7 @@
ide_drive_t *drive = get_drive_ptr (inode->i_rdev);
idetape_tape_t *tape;
idetape_pc_t pc;
- unsigned int minor=MINOR (inode->i_rdev);
+ unsigned int minor=minor(inode->i_rdev);
tape = drive->driver_data;
#if IDETAPE_DEBUG_LOG
^ permalink raw reply
* Re: Penelope builds a kernel
From: Thomas Duffy @ 2002-01-15 0:56 UTC (permalink / raw)
To: Bruce Harada; +Cc: esr, Linux Kernel Mailing List
In-Reply-To: <20020115073749.26b8f7a1.bruce@ask.ne.jp>
On Mon, 2002-01-14 at 14:37, Bruce Harada wrote:
> And before you say that Linux is supposed to empower the people of the world,
> not limit them, I wouldn't say that learning how to change my oil "empowers"
> me all that much.
You should read "Zen and the Art of Motorcycle Maintenance"
Notwithstanding the book being a great read, it is very relevant to this
whole discussion.
-tduffy
--
He who receives an idea from me, receives instruction himself without
lessening mine; as he who lights his taper at mine, receives light
without darkening me. -- Thomas Jefferson
^ permalink raw reply
* Re: [PATCH] fbdev currcon
From: Russell King @ 2002-01-15 0:56 UTC (permalink / raw)
To: James Simmons
Cc: Geert Uytterhoeven, Linux Fbdev development list,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.10.10201141618410.1714-100000@www.transvirtual.com>
On Mon, Jan 14, 2002 at 04:39:43PM -0800, James Simmons wrote:
> [stuff about currcon]
I've killed currcon completely in the cyber2000fb driver in favour of
tracking which struct display is current. Tracking 'currcon', doing
a whole pile of special cases, and copying 'var' stuff to/from fb.var
didn't make sense anymore. I'm expecting the same thing will happen
with the other stuff in the struct fb_info.
(Think about the current cyber2000fb code, and what happens to other
consoles when you fbset 800x600-60 -a and then switch to them to
discover you only have a 640x480 window where the characters appear).
--
Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
^ permalink raw reply
* Re: initrd failure on Linux-2.4.17
From: Jeff Chua @ 2002-01-15 0:50 UTC (permalink / raw)
To: Linux Kernel, Richard B. Johnson
In-Reply-To: <Pine.LNX.3.95.1020114103203.216A-100000@chaos.analogic.com>
On Mon, 14 Jan 2002, Richard B. Johnson wrote:
> RAMDISK: Compressed image found at block 0
> Freeing initrd memory: 581k freed
> kernel panic: VFS: Unable to mount root fs on 01:00
>
> Has somebody fixed this or is it expected that nobody uses
> an initial RAM disk on 2.4.17 ..or.. is this not the latest
> "stable" version of Linux to use?
RAMDISK: Compressed image found at block 0
Freeing initrd memory: 5384k freed
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 172k freed
I booted with Linux-2.4.0 up to 2.4.18-pre3.
Did you specify root=/dev/hda2 in your boot file?
Jeff.
^ permalink raw reply
* RE: [LARTC] Am I on the right Track?
From: Brendan Alderslade @ 2002-01-15 0:52 UTC (permalink / raw)
To: lartc
In-Reply-To: <marc-lartc-101101729200399@msgid-missing>
Sahil,
I'm assuming your network looks like this (appologies for bad ascii
graphics):
10.0.0.0/24 210.54.149.160/27
NET---[cisco]---------------[linux box]-----LAN/DMZ
Is that correct?
If so, your cisco needs to route 210.54.149.160/27 via 10.0.0.2 (eth0 on the
linux box), and your Linux box needs a default route via 10.0.0.1 so traffic
goes out via the cisco (if that is your default route!)
And that's it. There is no reason to add a route to the 210.54.149.160/27
range on the Linux box because it is directly connected to eth1.
> -----Original Message-----
> From: Sahil Gupta - NET4U [mailto:sahil@sahil.net.nz]
> Sent: Tuesday, January 15, 2002 12:39 PM
> To: lartc@mailman.ds9a.nl
> Subject: [LARTC] Am I on the right Track?
>
>
> Hi there,
> Is it possible to somehow have a fairly basic routing level
> in order to forward packets from eth1 to eth0? Simply using "route"?
>
> I have a Cisco that has a local network IP. It is on eth0
> interface. I have a Switch on eth1. I want to supply eth1
> with a Real World IP which comes through the Cisco.
>
> Any guidance available?
>
> I assigned 10.0.0.2 on eth0 and 210.54.149.189 on eth1.
> then I did this:
> route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1 dev
> eth0 route add -net 210.54.149.160 netmask 255.255.255.224 gw
> 10.0.0.1 (which says network unreachable)
>
> Could someone please tell me how I could solve this?
>
> Regards,
>
> Sahil Gupta
> NET4U Limited
>
> ------------------------------------
> NET4U -- www.net4u.co.nz
> Home of the new - $24.95 128k ADSL
> Nationwide Internet Service Provider
> ------------------------------------
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc > HOWTO:
> http://ds9a.nl/lartc/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
^ permalink raw reply
* Linux 2.5.1-dj15
From: Dave Jones @ 2002-01-15 0:51 UTC (permalink / raw)
To: Linux Kernel
Various pending items, and a merge with some of the bits from
Alan's new 2.4 branch. This one also includes some more experimental
bits, Aunt Tillie may want to give this one a miss.
Patch against 2.5.1 vanilla is available from:
ftp://ftp.xx.kernel.org/pub/linux/kernel/people/davej/patches/2.5/
-- Davej.
2.5.1-dj15
o Merge selective bits of 2.4.18pre3ac1 & ac2
| Drop rmap (except for rate-limit oom_kill change),
| IDE changes & 32bit uid quota
o Add 'nowayout' module param for watchdogs. (Matt Domsch)
o BSD partition fixes. (Andries Brouwer)
o wavelan_cs update (Jean Tourrilhes)
o Numerous LVM fixes. (andersg)
o Prevent ramdisk buffercache corruption. (Andrea Arcangeli)
o MS_ASYNC implementation. (Andrea, Andrew Morton)
o Truncate blocks when prepare_write() fails. (Andrea, Andrew Morton)
o winbond-840 OOM handling. (Manfred Spraul)
o Natsemi OOM handling. (Manfred Spraul)
o Eliminate some stalls in i386 syscall path. (Alex Khripin)
o Export release_console_sem() (Andrew Morton)
o Remove bogus sbp2 changes. (Christoph Hellwig)
o Remove i386 mmu_context.h (Me)
o Remove reiserfs build warnings. (Me)
o Fix ignorance of SCSI I/O errors. (Peter Osterlund)
o Fix IDE floppy thinko. (Luc Van Oostenryck)
o Radeonfb compile fixes. (Erik Andersen)
o Radeonfb flat panel support. (Michael Clark)
o Remove bogus extraneous return. (Paul Gortmaker)
o Fix potential oom-killer race. (Andres Salomon)
o Fix bio + highmem bounce BUG(). (Jens Axboe)
o PATH_MAX fixes. (Rusty Russell)
o Frame buffer _setcolreg changes. (James Simmons)
2.5.1-dj14
o Merge 2.5.2pre10 & pre11
| Also include Ingosched H7, so my testboxes now boot.
| Dropped Manfreds ldtgrow patch for now due to conflict.
o Merge 2.4.18pre2 & pre3
| DRM4.0 changes dropped.
| various SCSI layer changes dropped.
o Yet more kdev_t fixes. (Various)
o Fix potential ide-cd oops. (Zwane Mwaikambo)
o Reiserfs kmalloc cleanup. (Oleg Drokin)
o Reiserfs potential corruption fix. (Oleg Drokin)
o Reiserfs endian fixes. (Oleg Drokin)
o 64 bit cleanness for reiserfs. (Oleg Drokin)
o Fix 'sticky alt on chvt' problem. (James Simmons)
o Fix 3Dfx fbdev ROP ops namespace collision. (James Simmons)
o Console blanking improvement. (James Simmons)
o Multiple sound devices for OSS API. (Chris Rankin)
o Remove unneeded pidhash clearing. (Randy Dunlap)
o Allow enslaved devices with same ethernet address. (Lennert Buytenhek)
o Cleanup IDE casts. (Pavel Machek)
o Work around FAT fs __divdi generation. (Tom Rini)
o Print correct MCE address in bluesmoke. (Lowell Miles)
o Numerous 's/more then/more than/' (Me)
2.5.1-dj13
o Merge 2.5.2pre9
| Take akpm fix for ext3 over Linus' (Andrew Morton)
o More kdev_t fixes. (Various)
o Remerge acmes bio cleanups from -dj11 (Arnaldo Carvalho de Melo)
o Add __copy_to_user_prefetch() (Me)
o Clean up preload_cache() a little. (Me)
2.5.1-dj12
o Merge 2.5.2pre7
o Enable alternative PTE routines. (Andrea Arcangeli)
o Reschedule during inode flushes under mem pressure. (Andrea Arcangeli)
o More kdev_t compile fixes. (Andries Brouwer,
Jonathan Corbet,
Luc Van Oostenryck, Me)
o Further include file cleanups. (Me)
o aic7xxx nseg bugfix. (Jens Axboe, Others)
o Fix panic on corrupted reiserfs. (Oleg Drokin)
o Fix reiserfs taildata corruption on mempressure. (Oleg Drokin)
o Fix kreiserfsd sleep timeout thinko. (Oleg Drokin)
o apic.c LVTERR fixes. (Mikael Pettersson)
o Merge correct & updated sg driver. (Doug Gilbert)
o Add NetGear EA201 to ne2k ISAPNP clones. (Chris Rankin)
o Various 53c700 fixes. (James Bottomley)
2.5.1-dj11
o Merge up to 2.5.2pre6
| Plus various compile fixes. (Me, Jeff Garzik,
Frank Davis, Martin Dalecki)
o Don't enable APIC on newer Dell laptops. (Mikael Pettersson)
o Add more missing MODULE_LICENSE tags. (Me)
o Report out-of-spec SMP Athlons. (Me)
| Flames to /dev/null
o More fbdev/console clean up. (James Simmons)
o Sync up with latest bootproto. (H. Peter Anvin)
o Reiserfs Sparc alignment fix. (Alexander Zarochentcev)
o Remove some bogus headers left around. (Christoph Hellwig)
o Fix wanrouter build. (Me)
o Various bio surgery on SCSI drivers. (Arnaldo Carvalho de Melo)
o Reiserfs getblk cleanups. (Christoph Hellwig)
o make DASD use generic BLKGETSIZE{64} again (Christoph Hellwig)
o Fix devfs & tty breakage. (James Simmons)
2.5.1-dj10
o Remove one of the NFS changes. Better fix in mainline. (Me)
o Add switch to enable 486 string copies. (Me)
| 486 users please try this out, and give feedback
| so we can see how broken this actually is.
| It's in the 'kernel hacking' menu.
o JFFS2 corruption fix. (David Woodhouse)
o Bridging CONFIG_INET cleanup. (Lennert Buytenhek)
o Bridging recursion bugfix. (Lennert Buytenhek)
o Fix up port state handling. (Lennert Buytenhek)
o Improved fbdev init. (James Simmons)
o PNPOS simple bootflag fix. (Thomas Hood)
o Drop most of the USB changes on Greg's request.
| Newer versions should appear in -linus soon.
| Some bits still remain, but if I've broke it, blame
| me and not Greg.
o Experimental preload_cache() function. (Me)
o Ugly hack to file_read_actor() to use the above (Me)
| Just playing, this needs more work.
2.5.1-dj9
o Merge up to 2.5.2pre4.
| Also fix up a bunch of build errors.
o Add support for Sony DSC-P5 to USB unusual devs. (Gregor Jasny)
o First part of new console locking infrastructure. (James Simmons)
o Cleaner/Lighter fbdev api. (James Simmons,
Geert Uytterhoeven)
o Don't coredump framebuffer contents. (Andrew Morton)
o Fix hang on close of serial tty. (Russell King)
o Remove the set_current_state() patch, needs work. (Me)
o Drop ICH2 addition to ioapic Whitelist. (Me)
o Do the asm/segment.h crapectomy properly. (David Woodhouse)
o Reactivate the PNPBIOS Configure.help entry.
2.5.1-dj8
o Remove leftover EISA cruft in x86 ksyms. (Me)
o Add a missing part of the split visws support. (Me)
o Make reiserfs partitions mountable again. (Al Viro,
Andrew Morton, Me)
o Make x86 math emulation work with dynamic LDT. (Manfred Spraul)
o Fix problems with tdfxfb & high pixelclocks. (Jurriaan)
| Only tested on PCI 4500, feedback to thunder7@xs4all.nl
o Replace text.lock with .subsection (Keith Owens)
o Remove Cyrix SLOP workaround. (Me)
| Can be done in userspace/initramfs.
o Merge pnpbios support. (Thomas Hood)
| Should work, but may be nice to bend into shape
| to fit the new driverfs model at some point.
2.5.1-dj7
o Merge 2.5.2pre3
| Drop some of the reiserfs changes. Looks like -dj has
| a more complete set of fixes from 2.4. This is getting
| a little hairy, so handle with care.
o Make rootfs compile. (Me)
o Dynamically grow LDT. (Manfred Spraul)
o Randomness for ext2 generation numbers. (Manfred Spraul)
o Give Manfreds threaded coredump a retry. (Manfred Spraul)
o Add missing ad1848 formats. (Alan Cox)
o Make ide-floppy compile without PROC_FS. (Robert Love)
o generic_serial, rio_linux, serial_tx3912, (Rasmus Andersen)
sh-sci and sx drivers janitor work.
o opl3sa2 Power management support & update. (Zwane Mwaikambo)
| Add Zwane to MAINTAINERS for this too.
o Fix buggy MODINC i2o_config macro. (Andreas Dilger)
o Cyclades driver /proc/ioports oops fix. (Andrew Morton)
| Untested afaik, but looks sane.
| rmmod cyclades.o ; cat /proc/ioports to see if this works.
o SX driver, DCD-HylaFAX problem solved. (Heinz-Ado Arnolds)
o Only look in 1KB of EBDA for MP table. (Zwane Mwaikambo)
| Follows the MP1.4 Spec closer, let me know of any
| SMP problems if any with this change.
o Better fix for the sunrpc 'missing include'. (David Woodhouse)
o Remove bogus <asm/segment.h> includes. (David Woodhouse)
o ps2esdi spinlock typo. (Me)
2.5.1-dj6
o Merge 2.5.2pre2
| Includes updated for 2.5 SCSI debug driver. (Douglas Gilbert)
o Merge 2.4.18pre1
o Missing include in sunrpc sched.c (David S. Miller)
o Remove incorrect devinit's from bttv & USB. (Andrew Morton)
o Remove redundant EISA_bus__is_a_macro macro. (Me)
o Split visws support to setup-visws.c (Me)
| Can someone with one of these beasts test this, and maybe
| even *gulp* maintain it ?
o pc110pad spinlock thinko (Peter T. Breuer)
o Fix reiserfs + highmem possible oops. (Oleg Drokin)
o Fix reiserfs fsx breakage. (Oleg Drokin)
o Make IPV6 accept timestamps in response to SYNs. (Alexey Kuznetsov)
o NCR5380_timer_fn needs to be static. (Rasmus Andersen)
o CONFIG_SERIAL_ACPI is IA64 only. (Me)
2.5.1-dj5
o Sync up to 2.5.2pre1
o Merge 2.4.17final.
o Gravis ultrasound PnP update (Andrey Panin)
2.5.1-dj4
o Merge with 2.4.17-rc2
| Most was already here, more or less just fixes for
| reiserfs & netfilter, and some VM changes.
2.5.1-dj3
o Drop Manfreds multithread coredump changes (Me)
| They caused ltp waitpid05 regression on 2.5
| (Same patch is fine for 2.4)
o Intermezzo compile fix. (Chris Wright)
o Fix ymfpci & hisax merge errors. (Me)
o Drop ad1848 sound driver changes in favour of 2.5 (Me)
o Make hpfs work again. (Al Viro)
o Alpha Jensen compile fixes. (Ronald Lembcke)
o Make NCR5380 compile non modularly. (Erik Andersen)
2.5.1-dj2
o bio fixes for qlogicfas. (brett@bad-sports.com)
o Correct x86 CPU helptext. (Me)
o Fix serial.c __ISAPNP__ usage. (Andrey Panin)
o Use better ide-floppy fixes. (Jens Axboe)
o Make NFS 'fsx' proof. (Trond Mykelbust)
| 2 races & 4 bugs, hopefully this is all.
o devfs update (Richard Gooch)
o Backout early CPU init, needs more work. (Me)
| This should fix several strange reports.
o drop new POSIX kill semantics for now (Me)
2.5.1-dj1
o Resync with 2.5.1
| drop reiserfs changes. 2.4's look to be more complete.
o Fix potential sysvfs oops. (Christoph Hellwig)
o Loopback driver deadlock fix. (Andrea Arcangeli)
o __devexit cleanups in drivers/net/ (Daniel Chen,
synclink, wdt_pci & via82cxxx_audio John Tapsell)
o Configure.help updates (Eric S. Raymond)
o Make reiserfs compile again. (Me)
o bio changes for ide floppy (Me)
| handle with care, compiles, but is unfinished.
o Make x86 identify_cpu() happen earlier (Me)
| PPro errata workaround & APIC setup got a little
| cleaner as a result.
o Blink keyboard LEDs on panic (From 2.4.13-ac)
o Change current->state frobbing to set_current_state() (From 2.4.13-ac)
o Add MODULE_LICENSE tags for acpi,md.c,fmvj18x, (From 2.4.13-ac)
atyfb & fbmem.
--
Dave Jones. http://www.codemonkey.org.uk
SuSE Labs.
^ permalink raw reply
* Re: Penelope builds a kernel
From: Nathan Walp @ 2002-01-15 0:50 UTC (permalink / raw)
To: Eric S. Raymond, linux-kernel
In-Reply-To: <20020114165909.A20808@thyrsus.com>
[-- Attachment #1: Type: text/plain, Size: 3076 bytes --]
On Mon, Jan 14, 2002 at 04:59:09PM -0500, Eric S. Raymond wrote:
<snip of over-many-people's-heads description of advanced biology stuff>
> Penelope needs to build a kernel to support her exotic driver, but she
> hasn't got more than the vaguest idea how to go about it. The
> instructions with the driver source patch tell her to apply it at the
> top level of a current Linux source tree and then just say "build the
> kernel" before getting off into technicalia about the user-space
> tools.
>
> She could ask that guy who's been eyeing her over at the computer lab
> for help; Penelope knows what a penguin T-shirt means, and he's not
> too bad-looking, if a bit on the skinny side. On the other hand, she
> knows that guys like that tend to take over the whole process when
> they're trying to be helpful; they can't help displaying their prowess
> and doing more than you asked for, it's biologically wired in. And
> she's learned that letting someone else take over maintaining your
> equipment properly in a way you don't understand is a good way to have
> it flake out on you just short of a deadline.
>
> On the third hand, she really *doesn't* want to spend her think time
> absorbing a bunch of irrelevant hardware details just to get the one
> driver she needs up and running. What she needs is some fast,
> hassle-free technological empowerment, not Yet Another Learning
> Experience. (And a boyfriend would be nice too, while she's wishing.)
So can we assume that our dear sweet Penelope has spent a bit of time
reading l-k and finding out about <insert your favorite brown-paper-bag
release here>? We wouldn't want her to destroy her newly-created data.
Also, since she has a laptop (which comes with all that finicky laptop
hardware), does the release of the kernel she grabbed have that nasty
tweak that fries the board in her laptop? (I've heard some rather nasty
horror stories, that's why I ask)
She can't very well patch her vendor kernel, because I sincerely doubt
the patch will apply cleanly, if this driver is such that it needs a
patch as opposed to just a module.
Also, what do we tell Penelope when her other piece of exotic hardware
that *was* supported in the vendor kernel, but isn't supported in the
vanilla kernel, stops working. Suddenly she can do her advanced biology
stuff, but can't print, or dial up w/ her winmodem, or whatever.
> If Penelope learns from the README file that all *she* has to do is
> type "configure; make" to build a kernel that supports her hardware,
> she can apply that MEMS card patch and build with confidence that the
> effort is unlikely to turn into an infinite time sink.
>
> Autoconfigure saves the day again. That guy in the penguin T-shirt
> might even be impressed...
If Penelope is even a remote candidate for this scenario, I think
penguin-boy is already impressed ;-)
--
Nathan Walp || faceprint@faceprint.com
GPG Fingerprint: || http://faceprint.com/
5509 6EF3 928B 2363 9B2B DA17 3E46 2CDC 492D DB7E
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* oops in 2.4.17
From: rob @ 2002-01-15 0:47 UTC (permalink / raw)
To: linux-kernel
Hi
The ksymoops output is below
This happened when I started screen after logging in just after
booting. I'm not able to reproduce it. I've had a few hangs recently
on this machine so I'm trying to find out if it's software or
hardware.
config at http://mur.org.uk/~robbie/config-2.4.17
Script started on Tue Jan 15 00:29:48 2002
linux:~#uname -a
Linux linux 2.4.17 #1 SMP Mon Dec 31 00:09:27 GMT 2001 i686 unknown
linux:~#cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 451.028
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 897.84
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 2
cpu MHz : 451.028
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr
bogomips : 901.12
linux:~#lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0b.0 SCSI storage controller: Adaptec AIC-7880U
00:11.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02)
00:12.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02)
00:13.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:14.0 Unknown mass storage controller: Promise Technology, Inc. 20267 (rev 02)
linux:~#cat oops2.txt
ksymoops 2.4.3 on i686 2.4.17. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.4.17/ (default)
-m /boot/System.map-2.4.17 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c01f3160, System.map says c01530b0. Ignoring ksyms_base entry
invalid operand: 0000
CPU: 0
EIP: 0010:[<c0145df1>] Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 5a5a5a00 ebx: dc418c40 ecx: dc454d60 edx: dc418c70
esi: dcbf2d40 edi: c1941f20 ebp: dc418c40 esp: dc45feb8
ds: 0018 es: 0018 ss: 0018
Process screen (pid: 716, stackpage=dc45f000)
Stack: dc454d60 c016bd29 dc418c40 dc454d60 fffffff4 df32fb80 dc45e000 dc418c40
c1941f28 c02abba0 de3a7001 0023ee05 df6dbf40 c180ae20 c0145549 00000246
00000000 df32fb80 df32fbe8 df330b40 00000246 c0145c83 c1806288 000001f0
Call Trace: [<c016bd29>] [<c0145549>] [<c0145c83>] [<c013d67e>] [<c013ddb7>]
[<c013e01a>] [<c013e491>] [<c013b0cd>] [<c0141626>] [<c0106d7b>]
Code: 0f 0b f0 fe 0d a0 e6 2f c0 0f 88 bb bc 10 00 85 c9 74 12 8b
>>EIP; c0145df0 <d_instantiate+10/44> <=====
Trace; c016bd28 <devfs_lookup+1c0/20c>
Trace; c0145548 <dput+18/144>
Trace; c0145c82 <d_alloc+1a/178>
Trace; c013d67e <real_lookup+7a/108>
Trace; c013ddb6 <link_path_walk+596/7e0>
Trace; c013e01a <path_walk+1a/1c>
Trace; c013e490 <__user_walk+34/50>
Trace; c013b0cc <sys_stat64+18/70>
Trace; c0141626 <sys_ioctl+1ea/1f4>
Trace; c0106d7a <system_call+32/38>
Code; c0145df0 <d_instantiate+10/44>
00000000 <_EIP>:
Code; c0145df0 <d_instantiate+10/44> <=====
0: 0f 0b ud2a <=====
Code; c0145df2 <d_instantiate+12/44>
2: f0 fe 0d a0 e6 2f c0 lock decb 0xc02fe6a0
Code; c0145df8 <d_instantiate+18/44>
9: 0f 88 bb bc 10 00 js 10bcca <_EIP+0x10bcca> c0251aba <stext_lock+2cf2/8d98>
Code; c0145dfe <d_instantiate+1e/44>
f: 85 c9 test %ecx,%ecx
Code; c0145e00 <d_instantiate+20/44>
11: 74 12 je 25 <_EIP+0x25> c0145e14 <d_instantiate+34/44>
Code; c0145e02 <d_instantiate+22/44>
13: 8b 00 mov (%eax),%eax
2 warnings issued. Results may not be reliable.
linux:~#exit
Script done on Tue Jan 15 00:38:14 2002
--
Rob Murray
^ permalink raw reply
* Re: Aunt Tillie builds a kernel (was Re: ISA hardware discovery -- the elegant solution)
From: H. Peter Anvin @ 2002-01-15 0:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020115080218.7709cef7.bruce@ask.ne.jp>
Followup to: <20020115080218.7709cef7.bruce@ask.ne.jp>
By author: Bruce Harada <bruce@ask.ne.jp>
In newsgroup: linux.dev.kernel
>
> On Mon, 14 Jan 2002 17:34:23 -0500
> "Eric S. Raymond" <esr@thyrsus.com> wrote:
>
> > Therefore I try to stay focused on Aunt Tillie even though I know
> > that you are objectively correct and her class of user is likely
> > not to build kernels regularly for some years yet.
>
> Change that last line to read "her class of user will never build kernels ever,
> and would be aggressively disinterested in the possibility of doing so", and
> you might be closer to the truth.
>
> Aunt Tillie just DOESN'T CARE, OK? She can talk to her vendor if she gets
> worried about whether her kernel supports the Flangelistic2000 SuperDoodad.
>
I would make this an even stronger statement:
We (yes, we) should make sure Aunt Tillie doesn't ever have to build a
kernel, ever. If we have designed our kernels so that:
a) A distributor needs more than a handful of kernels (UP, SMP,
SMP+PAE, perhaps CMOV or not) on their install CD, or;
b) It's not possible to add a driver without rebuilding the kernel, or;
c) It's not possible to autodetect the module set needed AT RUNTIME;
then we have screwed up. Kernel compile autoconfiguration is a red
herring in that respect; I would argue if anything it hides the real
issue. We're currently crappy at both (b) and (c) -- a monolithic
kernel does (c) a lot better, and that is quite frankly unacceptable.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: results: Remove 8 bytes from struct page on 64bit archs
From: Dave Jones @ 2002-01-15 0:45 UTC (permalink / raw)
To: Anton Blanchard; +Cc: David S. Miller, linux-kernel
In-Reply-To: <20020114063531.GC18794@krispykreme>
On Mon, 14 Jan 2002, Anton Blanchard wrote:
> To follow up: Alan Modra found and fixed the bug, it seems we were only
> using the optimisation when the arguments were <= 32bit.
> The target we use is RS64a which has a cost of 60 odd instructions
> for divide.
Look forward to seeing the updated benchmarks.
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: MIPS64 status?
From: Ralf Baechle @ 2002-01-14 23:45 UTC (permalink / raw)
To: Matthew Dharm; +Cc: linux-mips
In-Reply-To: <NEBBLJGMNKKEEMNLHGAICENCCEAA.mdharm@momenco.com>
On Mon, Jan 14, 2002 at 03:25:44PM -0800, Matthew Dharm wrote:
> Thanks for the info. Too bad "MIPS64" and "mips64" sound exactly the
> same on the telephone.
>
> But, I need to be pedantic, just to be clear on a couple of
> questions...
>
> So, the "mips64" kernel can use 64-bits of address, for RAM >4G?
> But, the apps running are always 32-bit?
In theory the kernel has the capability to run 64-bit applications. In
practice that doesn't work due to the lack of 64-bit apps and stuff.
> Does this mean that any individual application can only use 4G of
> memory, tho you could have several applications in physical memory
> doing this? (i.e. multiple applications using 1G of RAM each, but not
> swapping to disk?)
In theory we don't limit the address space of 32-bit applications in 64-bit
mode so they could go and use all memory and syscalls on the 64-bit
address space also. In practice that's just too ugly to be usable so
consider 32-bit apps on the 64-bit kernel as limited to 2gb as they are
currently. You can however run an arbitrary number of these processes.
> Does this mean we could map PCI memory/IO addresses above 4G and have
> it work?
Sure.
Ralf
^ permalink raw reply
* Re: Hardwired drivers are going away?
From: H. Peter Anvin @ 2002-01-15 0:40 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020114232247.195bf441.spyro@armlinux.org>
Followup to: <20020114232247.195bf441.spyro@armlinux.org>
By author: Ian Molton <spyro@armlinux.org>
In newsgroup: linux.dev.kernel
>
> #2 Not all architectures have a problem with 'far' or 'near' calls, and
> frankly, I'm glad the kernels design isnt being crippled just to serve the
> fundamentally CRAP x86 architecture, for once.
>
Especially since the x86 *ISN'T* one of the architectures with this
particular problem. 'far' and 'near' as used in this thread don't
refer to the x86 segmentation crud.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* [PATCH] fbdev currcon
From: James Simmons @ 2002-01-15 0:39 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Fbdev development list, Linux Kernel Mailing List
This patch only applies for the -dj tree since the new fbdev api is going
in there for now. This patch makes every fbdev driver uses the currcon
that I have placed in struct fb_info. Currently most drivers have currcon,
not the one for the console system, global. This is a problem if you have
more than one card. I have tested to see if this compiles on ix86 but
this patch is extensive so I like people to apply this patch to test it
out against the dj14 tree. The patch is to big to post so it is avalibale
at the following link:
NOTE: The setcolreg patch has to be applied first.
http://www.transvirtual.com/~jsimmons/setcolreg.diff
http://www.transvirtual.com/~jsimmons/fbcurrcon.diff
. ---
|o_o |
|:_/ | Give Micro$oft the Bird!!!!
// \ \ Use Linux!!!!
(| | )
/'_ _/`\
___)=(___/
^ permalink raw reply
* Re: A few questions on older Macintosh Powerbooks
From: C S Rosenmund @ 2002-01-15 0:34 UTC (permalink / raw)
To: Michael Schmitz; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.33.0201141334110.8470-100000@opal.biophys.uni-duesseldorf.de>
I'm using that binary image myself, while trying to roll my own. I can
get the box to boot, and do most things with the 2.4.5 sources I have,
but any real loading and the MMU problem crops up. what I need is the
patches to make my hardware work:
PCMCIA (so I can use my NIC and get on the net)
MMU so I do not have to keep going back to a different kernel to try
other options when building the kernel)
and Media Bay (so I can use the CDROM as a software and data transfer
device. . .)
I'm not timid at all about building a kernel, nor about using patches to
fix the broken code, but I need to know where to *find* them
Michael Schmitz wrote:
>
> > Would someone tell me what the latest monolithic kernel and patch
> > available for a NuBus PPC would be and where they can be found? I'm
> > working with the 2.4.5 sources (and the patch-2.4.5-Nubus patch), and it
> > works *almost*. . .
>
> I'm using 2.4.6-pre3 from the SF site on a 6100 here, and it seems to work
> fine. nubus-pmac.sourceforge.net should be the site to look at.
>
> Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: [RFC] klibc requirements, round 2
From: H. Peter Anvin @ 2002-01-15 0:33 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20020114125433.A1357@thunk.org>
Followup to: <20020114125433.A1357@thunk.org>
By author: Theodore Tso <tytso@mit.edu>
In newsgroup: linux.dev.kernel
>
> Unfortunately, diet libc doesn't do shared libraries
>
That would seem to be major lose, no?
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: results: Remove 8 bytes from struct page on 64bit archs
From: Anton Blanchard @ 2002-01-14 6:35 UTC (permalink / raw)
To: Dave Jones, David S. Miller, linux-kernel
In-Reply-To: <20020106192204.B27356@twiddle.net>
> The powerpc backend claims to have a fast divide instruction
> (via RTX_COST if you care about such things). We'll replace
> with shift when dividing by powers of 2, but won't try the
> multiply by a constant inverse trick.
To follow up: Alan Modra found and fixed the bug, it seems we were only
using the optimisation when the arguments were <= 32bit.
The target we use is RS64a which has a cost of 60 odd instructions
for divide.
Anton
^ permalink raw reply
* Re: memory-mapped i/o barrier
From: Anton Blanchard @ 2002-01-14 6:24 UTC (permalink / raw)
To: davem, ralf, linux-kernel
In-Reply-To: <20020110134859.A729245@sgi.com>
Hi,
> Here's a copy of a patch I just got accepted into the 2.5 patch for
> ia64, and I'm wondering if you guys will accept something similar. On
> mips64, mmiob() could just be implemented as a 'sync', but I'm not
> sure how to do it (or if it's even necessary) on other platforms.
> Please let me know what you think. I wrote a small documentation file
> for the macro that appears at the top of the patch.
>
> Thanks,
> Jesse
>
>
> diff -Naur --exclude=*~ --exclude=TAGS linux-2.4.17-ia64/Documentation/mmio_barrier.txt linux-2.4.17-ia64-mmiob/Documentation/mmio_barrier.txt
> --- linux-2.4.17-ia64/Documentation/mmio_barrier.txt Wed Dec 31 16:00:00 1969
> +++ linux-2.4.17-ia64-mmiob/Documentation/mmio_barrier.txt Tue Jan 8 15:57:37 2002
> @@ -0,0 +1,15 @@
> +On some platforms, so-called memory-mapped I/O is weakly ordered. For
> +example, the following might occur:
> +
> +CPU A writes 0x1 to Device #1
> +CPU B writes 0x2 to Device #1
> +Device #1 sees 0x2
> +Device #1 sees 0x1
Can loads/stores also complete out of order to IO? (the example just shows
a store from one cpu passing one from another cpu)
On ppc32/ppc64 this can happen, it is fixed up in the low level pci
routines. Is there a case where you cant wrap it up in the low level
routines like ppc32/ppc64?
Anton
^ permalink raw reply
* [LARTC] Is it possible that connect to battle net from private IP network?
From: Lee, Myoung Ho @ 2002-01-15 0:30 UTC (permalink / raw)
To: lartc
Hi
I heard that some xDSL/Cable routers support battlenet and especially MSN
Messenger is fully supported including file transfer.
How they make it possible and which tools?
Do you have any idea?
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/
^ permalink raw reply
* Re: cross-cpu balancing with the new scheduler
From: Anton Blanchard @ 2002-01-14 6:10 UTC (permalink / raw)
To: Manfred Spraul; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <3C41BD74.28F6707A@colorfullife.com>
> eatcpu is a simple cpu hog ("for(;;);"). Dual CPU i386.
>
> $nice -19 ./eatcpu&;
> <wait>
> $nice -19 ./eatcpu&;
> <wait>
> $./eatcpu&.
>
> IMHO it should be
> * both niced process run on one cpu.
> * the non-niced process runs with a 100% timeslice.
>
> But it's the other way around:
> One niced process runs with 100%. The non-niced process with 50%, and
> the second niced process with 50%.
Rusty and I were talking about this recently. Would it make sense for
the load balancer to use a weighted queue length (sum up all priorities
in the queue?) instead of just balancing the queue length?
Anton
^ permalink raw reply
* RE: MIPS64 status?
From: Matthew Dharm @ 2002-01-15 0:27 UTC (permalink / raw)
To: Jason Gunthorpe; +Cc: linux-mips
In-Reply-To: <Pine.LNX.3.96.1020114165623.28388B-100000@wakko.deltatee.com>
Hrm...
Were you actually using 64-bit addresses on the PCI bus?
My guess is that with some creative address mappings, this could be
done. The PCI bus itself would use only 32-bit address, but the CPU
would use a base address offset into the >4G range.
Yeah, I could see how that could get ugly...
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: owner-linux-mips@oss.sgi.com
> [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Jason Gunthorpe
> Sent: Monday, January 14, 2002 4:00 PM
> To: Matthew Dharm
> Cc: linux-mips@oss.sgi.com
> Subject: RE: MIPS64 status?
>
>
>
> On Mon, 14 Jan 2002, Matthew Dharm wrote:
>
> > Does this mean we could map PCI memory/IO addresses above
> 4G and have
> > it work?
>
> Ooh, don't go there :> We looked at that and actually did
> it then backed
> it out.
>
> The PCI spec (particuarly PCI-X) tries to make it possible, but in a
> general system with PCI sockets/etc it is just is not feasible. PCI
> bridges need to be located below 4G, as do the majority of
> devices made.
> There is also a performance hit for having device registers > 4G.
>
> You'd definately need the mips64 kernel to do that, or use
> ugly wired TLB
> entries with normal mips.
>
> Jason
>
^ permalink raw reply
* Re: initramfs buffer spec -- second draft
From: H. Peter Anvin @ 2002-01-15 0:26 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <8GpxaCDXw-B@khms.westfalen.de>
Followup to: <8GpxaCDXw-B@khms.westfalen.de>
By author: kaih@khms.westfalen.de (Kai Henningsen)
In newsgroup: linux.dev.kernel
>
> The latest existing formal spec is probably POSIX 2001 (look under "pax").
> An older POSIX version would have it under "cpio". You'll probably also
> find it there in Unix98 a.k.a. SuSv2. (POSIX 2001 (the Austin revision)
> supersedes all of those.)
>
> It's a bit long to post here - probably exceeds fair use.
>
POSIX only specifies the "old ASCII" cpio format anyway, which is so
limited as to be useless. POSIX specifies also specify "ustar" and
"pax", two extended tar formats, neither of which is suitable for this
application.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* RE: MIPS64 status?
From: Matthew Dharm @ 2002-01-14 23:25 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
In-Reply-To: <20020114150554.A29242@dea.linux-mips.net>
Ralf --
Thanks for the info. Too bad "MIPS64" and "mips64" sound exactly the
same on the telephone.
But, I need to be pedantic, just to be clear on a couple of
questions...
So, the "mips64" kernel can use 64-bits of address, for RAM >4G?
But, the apps running are always 32-bit?
Does this mean that any individual application can only use 4G of
memory, tho you could have several applications in physical memory
doing this? (i.e. multiple applications using 1G of RAM each, but not
swapping to disk?)
Does this mean we could map PCI memory/IO addresses above 4G and have
it work?
Matt
--
Matthew D. Dharm Senior Software Designer
Momentum Computer Inc. 1815 Aston Ave. Suite 107
(760) 431-8663 X-115 Carlsbad, CA 92008-7310
Momentum Works For You www.momenco.com
> -----Original Message-----
> From: owner-linux-mips@oss.sgi.com
> [mailto:owner-linux-mips@oss.sgi.com]On Behalf Of Ralf Baechle
> Sent: Monday, January 14, 2002 3:06 PM
> To: Matthew Dharm
> Cc: linux-mips@oss.sgi.com
> Subject: Re: MIPS64 status?
>
>
> On Sun, Jan 13, 2002 at 09:13:23PM -0800, Matthew Dharm wrote:
>
> > As I understand it, 64-bit support is really two
> different things: 64-bit
> > data path (i.e. unsigned long long) and 64-bit addressing
> (for more than 4G
> > of RAM).
>
> Right but due to the CPU architecture of pre-MIPS64 CPUs
> they always come
> together unless the software does funny attempts at
> truncating OS support
> to just 32-bit. So the 32-bit kernel gives you none of the
> two, the mips64
> kernel both.
>
> > My understanding is that "MIPS64" generally refers to a
> kernel which
> > supports a 64-bit data path, but we're still limited to
> 32-bit addressing.
> > Is that correct?
>
> MIPS64 is MIPS's MIPS64 processor architecture, mips64 is
> the 64-bit kernel.
> That may sound like nitpicking but it's important to
> understand that both
> are not the same.
>
> > I suspect that this is very much a toolchain issue, as I
> don't think gcc
> > will generate 64-bit addressing code.
>
> Gcc is fine; the problem are binutils, that is as and ld.
> As a result of
> the gcc problems we don't have a 64-bit userspace either so
> all software
> running on 64-bit kernels is currently old 32-bit software
> running in
> compatibility mode.
>
> Ralf
>
^ permalink raw reply
* Re: MIPS64 status?
From: Ralf Baechle @ 2002-01-14 23:23 UTC (permalink / raw)
To: Kevin D. Kissell; +Cc: Dominic Sweetman, Matthew Dharm, linux-mips
In-Reply-To: <00ee01c19cfa$ab8d3640$0deca8c0@Ulysses>
On Mon, Jan 14, 2002 at 01:54:42PM +0100, Kevin D. Kissell wrote:
> The official MIPS64[tm] architecture spec from MIPS
> Technologies also provides a bit (Status.PX) which enables
> the 64-bit data path without affecting address generation
> and translation, which removes this quirk. Only the very
> most recent 64-bit cores and CPUs implement it, however.
And Linux doesn't use PX at all.
Ralf
^ permalink raw reply
* Re: MIPS64 status?
From: Ralf Baechle @ 2002-01-14 23:22 UTC (permalink / raw)
To: Dominic Sweetman; +Cc: Matthew Dharm, linux-mips
In-Reply-To: <15426.48692.795968.819750@gladsmuir.algor.co.uk>
On Mon, Jan 14, 2002 at 11:17:08AM +0000, Dominic Sweetman wrote:
> o Very large virtual address spaces, using 64-bit pointer types.
Actually I only implemented support for something like 0.5TB. As for
supercomputing that's peanuts (Like five years ago a customer requested
SGI to increase the per process size of the address space from 1TB, the
limit of the R4000 to 16TB, the limit of R10000 class processors.)
> o C "long" (and perhaps even "int") becomes 64-bit.
We follow the MIPS ABI which uses 32-bit ints and 64-bit longs.
> In such a 64-bit Linux system, though, you might still want to be able
> to run 32-bit applications with 32-bit pointers, int and long - either
> for compatibility or economy (32-bit data types make for a smaller
> program). SGI do this in Irix: I don't know whether the 64-bit
> Linux/MIPS systems got around to it.
Yes. The environment provided however is slightly different. 32-bit
software on the mips64 kernel is running with UX=1 thus 64-bit instructions
are allowed.
> There are other potentially useful combinations:
>
> o A Linux where all machine-supported integer data types are 32-bit,
I don't want to support 32-bit char and short, sorry :-)
> but capable of addressing physical memory outside of a 4Gbyte map.
> (In practice, you need to use this kind of system to get outside of
> a 512Mbyte map - so it's urgent).
I'd be working on this right now if you'd not be bothering me with email ;-)
> Ralf says he has done this: it could be done without using any
> 64-bit operations, but it might be easier with them.
There are still MIPS32 systems which don't support 64-bit operations just
may have an address space of upto 36 bits.
> o A system using 32-bit pointers and 'long' throughout, but with
> support for 'long long' 64-bit integer data types in registers.
>
> o A system using 64-bit addressing within the kernel, but not for
> applications.
>
> However, it's unlikely to make sense to do all of them!
Correct. We may add support for the one or other code of these models
over time.
> > I suspect that this is very much a toolchain issue, as I don't think
> > gcc will generate 64-bit addressing code.
>
> I suspect that the generic GNU toolchains are pretty buggy when you
> switch on 64-bit MIPS operation; but it's bug-fixes which are needed,
> not wholesale new features.
Actually in the past somebody was doing paid work to get the combo
g++ + SGI as + GNU ld to work for N32. Due to the similarity of N32 and
N64 that already brought us quite a bit closer to N64 support. That
still leaves alot of work including plenty of gas work.
> Politics: MIPS Technologies' advocacy for their "MIPS32" instruction
> set dialect in embedded systems means there are now some quite capable
> MIPS CPUs (eg Alchemy's 500Mhz integrated CPUs) which don't have
> 64-bit datapaths or arithmetic. So casual dependence on 64-bit
> operations should probably be avoided.
I'm doing the best to avoid that.
Ralf
^ 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.