* Re: Kernel headers git tree
From: David Woodhouse @ 2006-07-14 9:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0607132251310.5623@g5.osdl.org>
On Thu, 2006-07-13 at 22:52 -0700, Linus Torvalds wrote:
> Btw, I'm actually surprised that my path simplification didn't filter out
> the "." and make it mean exactly the same as not giving a path at all. I
> thought I had done that earlier, but if you say "-- ." matters, then it
> obviously does..
In this specific case where I have a whole bunch of commits which don't
actually change anything, it definitely does make a difference...
hera /home/dwmw2 $ export GIT_DIR=/pub/scm/linux/kernel/git/dwmw2/kernel-headers.git
hera /home/dwmw2 $ git-rev-list --max-count=5 stage1
e4e2fcc2c333aac5f6331c1df256ff28d7ee76d7
32ca8021c5ab7b9d44e8a08aeb53e52af5223fec
6b8380885464e069ae22e1e04f4a905c9e918f4e
2dee58696cab32506f655cb94a63cf4b18a13b37
402429bc9ac5eb891f253f6dae1228338f7f0ea5
hera /home/dwmw2 $ git-rev-list --max-count=5 stage1 -- .
d1aba9314210d616cd2aa9ee91176c1dba6d3834
0b627fd403d6319fe50fbd8b95d5ea02017731fa
b29cfa21bbdfc25271ef446b9df94ed8b5425711
e2407b6a9a643b378700474c9079dd8620e820ed
c0df084d3e2ec0df6dafda8099e7c27c29760843
Junio is right -- if I can avoid creating commits that don't change any
files in the stage1 branch, then I don't have to do this. That would be
_hard_ though...
Currently, the selection of commits from your original tree to be
represented in the stage1 branch is simple -- it's "those commits which
touch include/". And 'rev-list -- include' works nicely for that.
Yet what I actually want in the final result is "those commits which
change the result of the _exported_ headers". It's slightly less
realistic to want rev-list to find that for me directly from the
original kernel tree without having done the export step in stage1 --
what I need to do is create the exported header tree for each commit
which _might_ change it, then filter out the commits which don't
_actually_ change it.
The extra commits in the stage1 branch are cheap enough -- by definition
they don't lead to any extra tree or blob objects. I think the two-stage
export is probably the best approach, unless I'm missing something.
--
dwmw2
^ permalink raw reply
* [PATCH 2/3] Remove struct request_list from struct request
From: Jens Axboe @ 2006-07-14 9:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Jens Axboe
In-Reply-To: <11528701161633-git-send-email-axboe@suse.de>
It is always identical to &q->rq, and we only use it for detecting
whether this request came out of our mempool or not. So replace it
with an additional ->flags bit flag.
Signed-off-by: Jens Axboe <axboe@suse.de>
---
block/ll_rw_blk.c | 10 ++--------
include/linux/blkdev.h | 3 ++-
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/block/ll_rw_blk.c b/block/ll_rw_blk.c
index 0ed0e83..06b1fec 100644
--- a/block/ll_rw_blk.c
+++ b/block/ll_rw_blk.c
@@ -452,7 +452,6 @@ static void queue_flush(request_queue_t
rq->elevator_private = NULL;
rq->elevator_private2 = NULL;
rq->rq_disk = q->bar_rq.rq_disk;
- rq->rl = NULL;
rq->end_io = end_io;
q->prepare_flush_fn(q, rq);
@@ -478,7 +477,6 @@ static inline struct request *start_orde
rq->flags |= q->ordered & QUEUE_ORDERED_FUA ? REQ_FUA : 0;
rq->elevator_private = NULL;
rq->elevator_private2 = NULL;
- rq->rl = NULL;
init_request_from_bio(rq, q->orig_bar_rq->bio);
rq->end_io = bar_end_io;
@@ -1984,7 +1982,7 @@ blk_alloc_request(request_queue_t *q, in
* first three bits are identical in rq->flags and bio->bi_rw,
* see bio.h and blkdev.h
*/
- rq->flags = rw;
+ rq->flags = rw | REQ_ALLOCED;
if (priv) {
if (unlikely(elv_set_request(q, rq, bio, gfp_mask))) {
@@ -2162,7 +2160,6 @@ rq_starved:
ioc->nr_batch_requests--;
rq_init(q, rq);
- rq->rl = rl;
blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
out:
@@ -2646,8 +2643,6 @@ EXPORT_SYMBOL_GPL(disk_round_stats);
*/
void __blk_put_request(request_queue_t *q, struct request *req)
{
- struct request_list *rl = req->rl;
-
if (unlikely(!q))
return;
if (unlikely(--req->ref_count))
@@ -2656,13 +2651,12 @@ void __blk_put_request(request_queue_t *
elv_completed_request(q, req);
req->rq_status = RQ_INACTIVE;
- req->rl = NULL;
/*
* Request may not have originated from ll_rw_blk. if not,
* it didn't come out of our reserved rq pools
*/
- if (rl) {
+ if (req->flags & REQ_ALLOCED) {
int rw = rq_data_dir(req);
int priv = req->flags & REQ_ELVPRIV;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 575d3e8..1370687 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -183,7 +183,6 @@ struct request {
int ref_count;
request_queue_t *q;
- struct request_list *rl;
void *special;
char *buffer;
@@ -244,6 +243,7 @@ enum rq_flag_bits {
__REQ_PM_SHUTDOWN, /* shutdown request */
__REQ_ORDERED_COLOR, /* is before or after barrier */
__REQ_RW_SYNC, /* request is sync (O_DIRECT) */
+ __REQ_ALLOCED, /* request came from our alloc pool */
__REQ_NR_BITS, /* stops here */
};
@@ -274,6 +274,7 @@ #define REQ_PM_RESUME (1 << __REQ_PM_RES
#define REQ_PM_SHUTDOWN (1 << __REQ_PM_SHUTDOWN)
#define REQ_ORDERED_COLOR (1 << __REQ_ORDERED_COLOR)
#define REQ_RW_SYNC (1 << __REQ_RW_SYNC)
+#define REQ_ALLOCED (1 << __REQ_ALLOCED)
/*
* State information carried for REQ_PM_SUSPEND and REQ_PM_RESUME
--
1.4.1.ged0e0
^ permalink raw reply related
* [PATCHSET] Shrink struct request
From: Jens Axboe @ 2006-07-14 9:41 UTC (permalink / raw)
To: linux-kernel
Hi,
This patchset applies on top of what was sent yesterday. It shrinks
the size of struct request from 320 to 296 bytes on x86-64 by cleaning
up code and removing dead code.
--
Jens Axboe
^ permalink raw reply
* [Qemu-devel] qemu vl.c
From: Fabrice Bellard @ 2006-07-14 9:36 UTC (permalink / raw)
To: qemu-devel
CVSROOT: /sources/qemu
Module name: qemu
Changes by: Fabrice Bellard <bellard> 06/07/14 09:36:13
Modified files:
. : vl.c
Log message:
win32 compilation - force process affinity on win32 as a workaround for SMP issues
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/qemu/vl.c?cvsroot=qemu&r1=1.198&r2=1.199
^ permalink raw reply
* Re: ALC260 no sound output on Kernel 2.6.17.1
From: Barry Scott @ 2006-07-14 9:35 UTC (permalink / raw)
To: Lee Revell; +Cc: Takashi Iwai, alsa-devel
In-Reply-To: <1152831906.2961.0.camel@mindpipe>
Lee Revell wrote:
> On Fri, 2006-06-23 at 16:30 +0100, Barry Scott wrote:
>
>>> This should have been fixed in 1.0.12rc1.
>>>
>>>
>> Its the user land code that has the bug not the kernel drivers then?
>>
>
> Have you tried the ALSA 1.0.12rc1 kernel drivers yet?
>
> Lee
>
Yes it works. Something in the ALSA 1.0.12rc1 fixes it. I updated drivers,
lib and utils.
I was waiting for a reply to my messages asking which package I needed to
install. When no further info was forthcoming I explored all the kits.
I was surprised to see 2.6 drivers in the drivers package. All the previous
drivers packages tell me the drivers are shipped with linux kernel. Luck
I checked.
Barry
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
^ permalink raw reply
* Re: Problems after merge to 2.6.18-rc1
From: Rodolfo Giometti @ 2006-07-14 7:54 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20060714.103521.25910483.nemoto@toshiba-tops.co.jp>
[-- Attachment #1: Type: text/plain, Size: 3351 bytes --]
On Fri, Jul 14, 2006 at 10:35:21AM +0900, Atsushi Nemoto wrote:
>
> Two "Determined physycal RAM map:" line here. If both were printed in
> parse_cmdline_early() (i.e. parse_cmdline_early was called twice),
> something is seriously broken.
Yes, you was right. I fixed it! :)
However now I have another (strange) problem.
Attached you can find my patch to add power managament to the new
version of file "drivers/net/au1000_eth.c" that implements the
PHY-layer support.
Please, note the hack after the function mii_probe() called by
au1000_lowlevel_probe().
Kernel messages during suspend are:
hostname:~# apm --suspend
Stopping tasks: ===============================|
au1xxx_pm_prepare: state = 3
usbdev1.1_ep81: PM: suspend 0->2, parent 1-0:1.0 already 1
warning! Serial console ttyS0 is not disabled in debug kernel mode
au1xxx_pm_enter: state = 3
au_sleep: reason -3 force 0 wakeup 100 ticks 3000
au_sleep: Zzz...
au_sleep: Yep!
kobject_add failed for 0:1f with -EEXIST, don't try to register things with the same name in the same directory.
Call Trace:
[<80252ca8>] kobject_add+0x17c/0x1e0
[<80252b98>] kobject_add+0x6c/0x1e0
[<80292008>] device_add+0xc0/0x464
[<80291ff4>] device_add+0xac/0x464
[<802a2e64>] mdiobus_register+0x134/0x198
[<802a3ac0>] au1000_lowlevel_probe+0x104/0x4b4
[<802a58a4>] au1000_drv_resume+0x3c/0xc8
[<80138978>] process_timeout+0x0/0x8
[<80298610>] platform_resume+0x34/0x40
[<8029bf7c>] resume_device+0x19c/0x200
[<802528e4>] kobject_get+0x20/0x34
[<8029391c>] __sysdev_resume+0xf0/0xf8
[<80291da4>] get_device+0x20/0x34
[<8029c1c4>] dpm_resume+0x1e4/0x3c0
[<8029c3fc>] device_resume+0x5c/0x174
[<80153848>] enter_state+0x290/0x314
[<80153840>] enter_state+0x288/0x314
[<8010e824>] apm_suspend+0x1c/0xa0
[<80219750>] nfs_getattr+0x88/0xf8
[<80219708>] nfs_getattr+0x40/0xf8
[<8010eca8>] apm_ioctl+0x198/0x22c
[<80110e84>] do_page_fault+0x364/0x3d0
[<80110c24>] do_page_fault+0x104/0x3d0
[<801a0d24>] do_ioctl+0x54/0x90
[<801a0f6c>] vfs_ioctl+0x20c/0x394
[<801b7950>] sync_inodes+0x20/0x54
[<801a1144>] sys_ioctl+0x50/0x9c
[<8010f66c>] stack_done+0x20/0x40
[<8010f66c>] stack_done+0x20/0x40
phy 31 failed to register
au1000_eth_mii: probed
eth0: 0:1f already attached
eth0: Could not attach to PHY
usb usb1: root hub lost power or was reset
Restarting tasks... done
au1xxx_pm_finish: state = 3
hostname:~#
The first strange thing is that this time the kernel messages stop
after "au1xxx_pm_prepare: state = 3" and not after "au_sleep: Zzz..."
as before the merge! Maybe something as changed in serial console
magement?
The second strange thing is that _only_ calling the mii_probe()
the resume works correctly, otherwise the CPU loops forever
calling the au1000_lowlevel_probe() without showing the printk()
messages through the serial console. =:-o
Suggestions?
Ciao,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [U-Boot-Users] skipping bad blocks when erasing nand
From: Wolfgang Denk @ 2006-07-14 9:29 UTC (permalink / raw)
To: u-boot
In-Reply-To: <200607141047.08126.sr@denx.de>
Dear Stefan,
in message <200607141047.08126.sr@denx.de> you wrote:
>
> I find it hard to believe that a linux NAND erase operation will stop upon
> reaching a bad block. But you are right: the code in question is the same in
> the current linux mtd driver. From my experience, I never had problems
> erasing NAND flash devices (from U-Boot & linux) which had bad blocks.
The code in the MTD CVS is also the same.
Note that in my understanding this code never gets executed for bad
blocks (see comment "we do not erase bad blocks") in Linux, i. e. it
attempts to catch previous errors.
> I see. You have a good point here. This needs some testing on a device with
> bad blocks. "Unfortunately" the device on my desk has no bad blocks at all:
>
> => nand bad
>
> Device 0 bad blocks:
>
> Perhaps somebody else can jump in here and test the current linux mtd driver
> behavior on a device with bad blocks. Thanks.
If you like you can use the "dave" board in our virtual lab. It has a
couple of bad blocks in device 1:
=> nand device 1
Device 1: NAND 32MiB 3,3V 8-bit... is now current device
=> nand bad
Device 1 bad blocks:
00000000
00004000
00008000
0000c000
00010000
=>
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I don't know if it's what you want, but it's what you get. :-)
- Larry Wall in <10502@jpl-devvax.JPL.NASA.GOV>
^ permalink raw reply
* [LARTC] how different qdisc at root and leaf working???
From: *~ r a K u ~ * @ 2006-07-14 9:28 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/html, Size: 1370 bytes --]
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply
* Re: disabling caching
From: Frank van Maarseveen @ 2006-07-14 9:26 UTC (permalink / raw)
To: Stefan Palme; +Cc: Linux NFS mailing list
In-Reply-To: <1152864752.28625.30.camel@devel.office.ancoso-development.de>
On Fri, Jul 14, 2006 at 10:12:32AM +0200, Stefan Palme wrote:
>
> After a few seconds, the open() call on the second box succeeds.
> So I guess that caching is the reason for the second open()-call
> to fail.
You might want to try (1) and/or ((2) or (3)) on the NFS client:
(1) On the NFS client, put this before the open():
close(open("whatever", O_WRONLY|O_CREAT, 0666));
unlink("whatever");
(2) Try the "noac" nfs mount option, it'll cost performance though.
(3) Another solution might be to use the patch at www.frankvm.com/nfs-noac
to selectively disable attribute caching (see the README). It's a trick
I use for some distributed work.
--
Frank
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* [PATCH] nvram driver cleanups
From: Johannes Weiner @ 2006-07-14 9:25 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 66 bytes --]
Style adjustance in the nvram driver. Nothing functional changed.
[-- Attachment #2: nvram_minor_fixes.patch --]
[-- Type: text/plain, Size: 11902 bytes --]
diff --git a/drivers/char/nvram.c b/drivers/char/nvram.c
index a39f19c..1df5900 100644
--- a/drivers/char/nvram.c
+++ b/drivers/char/nvram.c
@@ -28,13 +28,15 @@
* drivers, this is the case on the Atari.
*
*
- * 1.1 Cesar Barros: SMP locking fixes
- * added changelog
- * 1.2 Erik Gilling: Cobalt Networks support
- * Tim Hockin: general cleanup, Cobalt support
+ * 1.1 Cesar Barros: SMP locking fixes
+ * added changelog
+ * 1.2 Erik Gilling: Cobalt Networks support
+ * Tim Hockin: general cleanup, Cobalt support
+ * 1.3 Johannes Weiner: Minor cleanups, small
+ * improvements, style adjustance
*/
-#define NVRAM_VERSION "1.2"
+#define NVRAM_VERSION "1.3"
#include <linux/module.h>
#include <linux/sched.h>
@@ -45,24 +47,22 @@ #define PC 1
#define ATARI 2
#define COBALT 3
-/* select machine configuration */
+/* Select machine configuration */
#if defined(CONFIG_ATARI)
# define MACH ATARI
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) /* and others?? */
-#define MACH PC
+# define MACH PC
# if defined(CONFIG_COBALT)
# include <linux/cobalt-nvram.h>
# define MACH COBALT
-# else
-# define MACH PC
# endif
#else
# error Cannot build nvram driver for this machine configuration.
#endif
-#if MACH == PC
+/* Architecture related definitions */
+#if (MACH == PC)
-/* RTC in a PC */
#define CHECK_DRIVER_INIT() 1
/* On PCs, the checksum is built only over bytes 2..31 */
@@ -75,9 +75,7 @@ #define mach_check_checksum pc_check_che
#define mach_set_checksum pc_set_checksum
#define mach_proc_infos pc_proc_infos
-#endif
-
-#if MACH == COBALT
+#elif (MACH == COBALT)
#define CHECK_DRIVER_INIT() 1
@@ -87,9 +85,7 @@ #define mach_check_checksum cobalt_check
#define mach_set_checksum cobalt_set_checksum
#define mach_proc_infos cobalt_proc_infos
-#endif
-
-#if MACH == ATARI
+#elif (MACH == ATARI)
/* Special parameters for RTC in Atari machines */
#include <asm/atarihw.h>
@@ -153,7 +149,7 @@ #endif
*
* It is worth noting that these functions all access bytes of general
* purpose memory in the NVRAM - that is to say, they all add the
- * NVRAM_FIRST_BYTE offset. Pass them offsets into NVRAM as if you did not
+ * NVRAM_FIRST_BYTE offset. Pass them offsets into NVRAM as if you did not
* know about the RTC cruft.
*/
@@ -216,18 +212,6 @@ __nvram_set_checksum(void)
mach_set_checksum();
}
-#if 0
-void
-nvram_set_checksum(void)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&rtc_lock, flags);
- __nvram_set_checksum();
- spin_unlock_irqrestore(&rtc_lock, flags);
-}
-#endif /* 0 */
-
/*
* The are the file operation function for user access to /dev/nvram
*/
@@ -274,7 +258,7 @@ nvram_read(struct file *file, char __use
return tmp - contents;
- checksum_err:
+checksum_err:
spin_unlock_irq(&rtc_lock);
return -EIO;
}
@@ -307,7 +291,7 @@ nvram_write(struct file *file, const cha
return tmp - contents;
- checksum_err:
+checksum_err:
spin_unlock_irq(&rtc_lock);
return -EIO;
}
@@ -335,7 +319,7 @@ nvram_ioctl(struct inode *inode, struct
return 0;
case NVRAM_SETCKS:
- /* just set checksum, contents unchanged (maybe useful after
+ /* just set checksum, contents unchanged (maybe useful after
* checksum garbaged somehow...) */
if (!capable(CAP_SYS_ADMIN))
return -EACCES;
@@ -357,14 +341,14 @@ nvram_open(struct inode *inode, struct f
if ((nvram_open_cnt && (file->f_flags & O_EXCL)) ||
(nvram_open_mode & NVRAM_EXCL) ||
- ((file->f_mode & 2) && (nvram_open_mode & NVRAM_WRITE))) {
+ ((file->f_mode & S_IWOTH) && (nvram_open_mode & NVRAM_WRITE))) {
spin_unlock(&nvram_state_lock);
return -EBUSY;
}
if (file->f_flags & O_EXCL)
nvram_open_mode |= NVRAM_EXCL;
- if (file->f_mode & 2)
+ if (file->f_mode & S_IWOTH)
nvram_open_mode |= NVRAM_WRITE;
nvram_open_cnt++;
@@ -383,7 +367,7 @@ nvram_release(struct inode *inode, struc
/* if only one instance is open, clear the EXCL bit */
if (nvram_open_mode & NVRAM_EXCL)
nvram_open_mode &= ~NVRAM_EXCL;
- if (file->f_mode & 2)
+ if (file->f_mode & S_IWOTH)
nvram_open_mode &= ~NVRAM_WRITE;
spin_unlock(&nvram_state_lock);
@@ -448,9 +432,9 @@ static const struct file_operations nvra
};
static struct miscdevice nvram_dev = {
- NVRAM_MINOR,
- "nvram",
- &nvram_fops
+ .minor = NVRAM_MINOR,
+ .name = "nvram",
+ .fops = &nvram_fops
};
static int __init
@@ -464,23 +448,23 @@ nvram_init(void)
ret = misc_register(&nvram_dev);
if (ret) {
- printk(KERN_ERR "nvram: can't misc_register on minor=%d\n",
- NVRAM_MINOR);
+ printk(KERN_ERR "nvram: can't misc_register "
+ "on minor=%d\n", NVRAM_MINOR);
goto out;
}
- if (!create_proc_read_entry("driver/nvram", 0, NULL, nvram_read_proc,
- NULL)) {
+ if (!create_proc_read_entry("driver/nvram", 0, NULL,
+ nvram_read_proc, NULL)) {
printk(KERN_ERR "nvram: can't create /proc/driver/nvram\n");
ret = -ENOMEM;
goto outmisc;
}
ret = 0;
printk(KERN_INFO "Non-volatile memory driver v" NVRAM_VERSION "\n");
- out:
- return ret;
- outmisc:
+
+outmisc:
misc_deregister(&nvram_dev);
- goto out;
+out:
+ return ret;
}
static void __exit
@@ -497,7 +481,7 @@ module_exit(nvram_cleanup_module);
* Machine specific functions
*/
-#if MACH == PC
+#if (MACH == PC)
static int
pc_check_checksum(void)
@@ -508,8 +492,10 @@ pc_check_checksum(void)
for (i = PC_CKS_RANGE_START; i <= PC_CKS_RANGE_END; ++i)
sum += __nvram_read_byte(i);
+
expect = __nvram_read_byte(PC_CKS_LOC)<<8 |
- __nvram_read_byte(PC_CKS_LOC+1);
+ __nvram_read_byte(PC_CKS_LOC+1);
+
return ((sum & 0xffff) == expect);
}
@@ -521,6 +507,7 @@ pc_set_checksum(void)
for (i = PC_CKS_RANGE_START; i <= PC_CKS_RANGE_END; ++i)
sum += __nvram_read_byte(i);
+
__nvram_write_byte(sum >> 8, PC_CKS_LOC);
__nvram_write_byte(sum & 0xff, PC_CKS_LOC + 1);
}
@@ -582,30 +569,28 @@ pc_proc_infos(unsigned char *nvram, char
PRINT_PROC("none\n");
PRINT_PROC("HD type 48 data: %d/%d/%d C/H/S, precomp %d, lz %d\n",
- nvram[18] | (nvram[19] << 8),
- nvram[20], nvram[25],
- nvram[21] | (nvram[22] << 8), nvram[23] | (nvram[24] << 8));
+ nvram[18] | (nvram[19] << 8),
+ nvram[20], nvram[25],
+ nvram[21] | (nvram[22] << 8), nvram[23] | (nvram[24] << 8));
PRINT_PROC("HD type 49 data: %d/%d/%d C/H/S, precomp %d, lz %d\n",
- nvram[39] | (nvram[40] << 8),
- nvram[41], nvram[46],
- nvram[42] | (nvram[43] << 8), nvram[44] | (nvram[45] << 8));
+ nvram[39] | (nvram[40] << 8),
+ nvram[41], nvram[46],
+ nvram[42] | (nvram[43] << 8), nvram[44] | (nvram[45] << 8));
PRINT_PROC("DOS base memory: %d kB\n", nvram[7] | (nvram[8] << 8));
PRINT_PROC("Extended memory: %d kB (configured), %d kB (tested)\n",
- nvram[9] | (nvram[10] << 8), nvram[34] | (nvram[35] << 8));
+ nvram[9] | (nvram[10] << 8), nvram[34] | (nvram[35] << 8));
PRINT_PROC("Gfx adapter : %s\n", gfx_types[(nvram[6] >> 4) & 3]);
PRINT_PROC("FPU : %sinstalled\n",
- (nvram[6] & 2) ? "" : "not ");
+ (nvram[6] & 2) ? "" : "not ");
return 1;
}
#endif
-#endif /* MACH == PC */
-
-#if MACH == COBALT
+#elif (MACH == COBALT)
/* the cobalt CMOS has a wider range of its checksum */
static int cobalt_check_checksum(void)
@@ -620,8 +605,10 @@ static int cobalt_check_checksum(void)
sum += __nvram_read_byte(i);
}
+
expect = __nvram_read_byte(COBT_CMOS_CHECKSUM) << 8 |
- __nvram_read_byte(COBT_CMOS_CHECKSUM+1);
+ __nvram_read_byte(COBT_CMOS_CHECKSUM+1);
+
return ((sum & 0xffff) == expect);
}
@@ -659,8 +646,8 @@ static int cobalt_proc_infos(unsigned ch
PRINT_PROC("Checksum status: %svalid\n", checksum ? "" : "not ");
- flags = nvram[COBT_CMOS_FLAG_BYTE_0] << 8
- | nvram[COBT_CMOS_FLAG_BYTE_1];
+ flags = nvram[COBT_CMOS_FLAG_BYTE_0] << 8 |
+ nvram[COBT_CMOS_FLAG_BYTE_1];
PRINT_PROC("Console: %s\n",
flags & COBT_CMOS_CONSOLE_FLAG ? "on": "off");
@@ -731,15 +718,13 @@ static int cobalt_proc_infos(unsigned ch
nvram[COBT_CMOS_BOOTCOUNT_3]);
/* 13 bytes of serial num */
- for (i=0 ; i<13 ; i++) {
+ for (i=0 ; i<13 ; i++)
sernum[i] = nvram[COBT_CMOS_SYS_SERNUM_0 + i];
- }
sernum[13] = '\0';
checksum = 0;
- for (i=0 ; i<13 ; i++) {
+ for (i=0 ; i<13 ; i++)
checksum += sernum[i] ^ key[i];
- }
checksum = ((checksum & 0x7f) ^ (0xd6)) & 0xff;
PRINT_PROC("Serial Number: %s", sernum);
@@ -761,8 +746,8 @@ static int cobalt_proc_infos(unsigned ch
}
PRINT_PROC("\n");
- if (flags & COBT_CMOS_VERSION_FLAG
- && nvram[COBT_CMOS_VERSION] >= COBT_CMOS_VER_BTOCODE) {
+ if (flags & COBT_CMOS_VERSION_FLAG &&
+ nvram[COBT_CMOS_VERSION] >= COBT_CMOS_VER_BTOCODE) {
PRINT_PROC("BTO Code: 0x%x\n",
nvram[COBT_CMOS_BTO_CODE_0] << 24 |
nvram[COBT_CMOS_BTO_CODE_1] << 16 |
@@ -774,9 +759,7 @@ static int cobalt_proc_infos(unsigned ch
}
#endif /* CONFIG_PROC_FS */
-#endif /* MACH == COBALT */
-
-#if MACH == ATARI
+#elif (MACH == ATARI)
static int
atari_check_checksum(void)
@@ -786,8 +769,9 @@ atari_check_checksum(void)
for (i = ATARI_CKS_RANGE_START; i <= ATARI_CKS_RANGE_END; ++i)
sum += __nvram_read_byte(i);
+
return (__nvram_read_byte(ATARI_CKS_LOC) == (~sum & 0xff) &&
- __nvram_read_byte(ATARI_CKS_LOC + 1) == (sum & 0xff));
+ __nvram_read_byte(ATARI_CKS_LOC + 1) == (sum & 0xff));
}
static void
@@ -798,6 +782,7 @@ atari_set_checksum(void)
for (i = ATARI_CKS_RANGE_START; i <= ATARI_CKS_RANGE_END; ++i)
sum += __nvram_read_byte(i);
+
__nvram_write_byte(~sum, ATARI_CKS_LOC);
__nvram_write_byte(sum, ATARI_CKS_LOC + 1);
}
@@ -853,17 +838,17 @@ atari_proc_infos(unsigned char *nvram, c
PRINT_PROC("Checksum status : %svalid\n", checksum ? "" : "not ");
PRINT_PROC("Boot preference : ");
- for (i = ARRAY_SIZE(boot_prefs) - 1; i >= 0; --i) {
+ for (i = ARRAY_SIZE(boot_prefs) - 1; i >= 0; --i)
if (nvram[1] == boot_prefs[i].val) {
PRINT_PROC("%s\n", boot_prefs[i].name);
break;
}
- }
+
if (i < 0)
PRINT_PROC("0x%02x (undefined)\n", nvram[1]);
PRINT_PROC("SCSI arbitration : %s\n",
- (nvram[16] & 0x80) ? "on" : "off");
+ (nvram[16] & 0x80) ? "on" : "off");
PRINT_PROC("SCSI host ID : ");
if (nvram[16] & 0x80)
PRINT_PROC("%d\n", nvram[16] & 7);
@@ -886,31 +871,31 @@ atari_proc_infos(unsigned char *nvram, c
PRINT_PROC("%u (undefined)\n", nvram[7]);
PRINT_PROC("Date format : ");
PRINT_PROC(dateformat[nvram[8] & 7],
- nvram[9] ? nvram[9] : '/', nvram[9] ? nvram[9] : '/');
+ nvram[9] ? nvram[9] : '/', nvram[9] ? nvram[9] : '/');
PRINT_PROC(", %dh clock\n", nvram[8] & 16 ? 24 : 12);
PRINT_PROC("Boot delay : ");
if (nvram[10] == 0)
PRINT_PROC("default");
else
PRINT_PROC("%ds%s\n", nvram[10],
- nvram[10] < 8 ? ", no memory test" : "");
+ nvram[10] < 8 ? ", no memory test" : "");
vmode = (nvram[14] << 8) || nvram[15];
PRINT_PROC("Video mode : %s colors, %d columns, %s %s monitor\n",
- colors[vmode & 7],
- vmode & 8 ? 80 : 40,
- vmode & 16 ? "VGA" : "TV", vmode & 32 ? "PAL" : "NTSC");
+ colors[vmode & 7],
+ vmode & 8 ? 80 : 40,
+ vmode & 16 ? "VGA" : "TV", vmode & 32 ? "PAL" : "NTSC");
PRINT_PROC(" %soverscan, compat. mode %s%s\n",
- vmode & 64 ? "" : "no ",
- vmode & 128 ? "on" : "off",
- vmode & 256 ?
- (vmode & 16 ? ", line doubling" : ", half screen") : "");
+ vmode & 64 ? "" : "no ",
+ vmode & 128 ? "on" : "off",
+ vmode & 256 ?
+ (vmode & 16 ? ", line doubling" : ", half screen") : "");
return 1;
}
#endif
-#endif /* MACH == ATARI */
+#endif /* Architecture specifics */
MODULE_LICENSE("GPL");
@@ -920,4 +905,5 @@ EXPORT_SYMBOL(__nvram_write_byte);
EXPORT_SYMBOL(nvram_write_byte);
EXPORT_SYMBOL(__nvram_check_checksum);
EXPORT_SYMBOL(nvram_check_checksum);
+
MODULE_ALIAS_MISCDEV(NVRAM_MINOR);
^ permalink raw reply related
* Re: 18rc1 soft lockup
From: Roman Zippel @ 2006-07-14 9:22 UTC (permalink / raw)
To: Dave Jones; +Cc: john stultz, Linux Kernel
In-Reply-To: <20060713222830.GC3371@redhat.com>
Hi,
On Thu, 13 Jul 2006, Dave Jones wrote:
> On Thu, Jul 13, 2006 at 03:15:43PM -0700, john stultz wrote:
>
> > > Just when I thought it had gotten fixed..
> > > 2.6.18rc1-git6 this time on x86-64..
> > >
> > > BUG: soft lockup detected on CPU#3!
> > >
> > > Call Trace:
> > > [<ffffffff80270865>] show_trace+0xaa/0x23d
> > > [<ffffffff80270a0d>] dump_stack+0x15/0x17
> > > [<ffffffff802c44e6>] softlockup_tick+0xd5/0xea
> > > [<ffffffff80250bea>] run_local_timers+0x13/0x15
> > > [<ffffffff8029cc1d>] update_process_times+0x4c/0x79
> > > [<ffffffff8027bfeb>] smp_local_timer_interrupt+0x2b/0x50
> > > [<ffffffff8027c766>] smp_apic_timer_interrupt+0x58/0x62
> > > [<ffffffff802628ae>] apic_timer_interrupt+0x6a/0x70
> >
> > Hmmm.. grumble. Was this on bootup, or after some time period?
>
> Right at the end of boot up, between the switch from runlevel 3 to 5.
When it waits, a SysRq+T might be useful.
bye, Roman
^ permalink raw reply
* Re: [PATCH] Rt-tester makes freezing processes fail.
From: Rafael J. Wysocki @ 2006-07-14 8:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: nigel, torvalds, linux-kernel, tglx, linux-pm, Pavel Machek
In-Reply-To: <20060713163743.e71975b0.akpm@osdl.org>
On Friday 14 July 2006 01:37, Andrew Morton wrote:
> On Fri, 14 Jul 2006 09:18:43 +1000
> Nigel Cunningham <nigel@suspend2.net> wrote:
>
> > Compiling in the rt-tester currently makes freezing processes fail.
> > I don't think there's anything wrong with it running during
> > suspending, so adding PF_NOFREEZE to the flags set seems to be the
> > right solution.
> >
> > Signed-off-by: Nigel Cunningham <nigel@suspend2.net>
> >
> > rtmutex-tester.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > diff -ruNp 9971-rt-tester.patch-old/kernel/rtmutex-tester.c 9971-rt-tester.patch-new/kernel/rtmutex-tester.c
> > --- 9971-rt-tester.patch-old/kernel/rtmutex-tester.c 2006-07-07 10:27:46.000000000 +1000
> > +++ 9971-rt-tester.patch-new/kernel/rtmutex-tester.c 2006-07-14 07:48:01.000000000 +1000
> > @@ -259,7 +259,7 @@ static int test_func(void *data)
> > struct test_thread_data *td = data;
> > int ret;
> >
> > - current->flags |= PF_MUTEX_TESTER;
> > + current->flags |= PF_MUTEX_TESTER | PF_NOFREEZE;
> > allow_signal(SIGHUP);
> >
> > for(;;) {
>
>
> I yesterday queued up the below patch. Which approach is most appropriate?
I prefer the one that makes these threads freeze (ie. the Luca's patch).
Greetings,
Rafael
^ permalink raw reply
* Re: Fwd: Using select in boolean dependents of a tristate symbol
From: Roman Zippel @ 2006-07-14 9:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel
In-Reply-To: <200607132231.46776.dtor@insightbb.com>
Hi,
On Thu, 13 Jul 2006, Dmitry Torokhov wrote:
> On Thursday 13 July 2006 18:58, Roman Zippel wrote:
> > Hi,
> >
> > On Thu, 13 Jul 2006, Dmitry Torokhov wrote:
> >
> > > config THRUSTMASTER_FF
> > > bool "ThrustMaster FireStorm Dual Power 2 support (EXPERIMENTAL)"
> > > depends on HID_FF && EXPERIMENTAL
> > > + select INPUT_FF_MEMLESS
> > > help
> > > Say Y here if you have a THRUSTMASTER FireStore Dual Power 2,
> > > and want to enable force feedback support for it.
> > >
> > > Unfortunately this forces INPUT_FF_MEMLESS to always be built-in,
> > > although if HID is a module it could be a module as well. Do you have
> > > any suggestions as to how allow INPUT_FF_MEMLESS to be compiled as a
> > > module?
> >
> > You need to directly include HID into the dependencies, only the direct
> > dependencies for config entry are used for the select.
> >
>
> Oh, this indeed works, thanks a lot! And I was thinking I would need to
> implement something like "select <expr> as <expr>" in kconfig ;)
What you could do is to use "select INPUT_FF_MEMLESS if HID" to make it
visible that this dependency is actually for select.
This point is a little subtle and I'm not completely happy with it, maybe
I'm going to split this into two select variations - one which includes
all the dependencies and one which only uses the config symbol to select.
bye, Roman
^ permalink raw reply
* allowing yahoo messenger even if blocked by firewall
From: manish Jamwal @ 2006-07-14 9:14 UTC (permalink / raw)
To: netfilter
hi all
Can anyone tell me how to allow yahoo messenger even if it blocked by firewall.
I am not able to access company firewall.
manish
^ permalink raw reply
* Re: [Bluez-devel] [PATCH] bluetooth: use kthread_ API
From: Marcel Holtmann @ 2006-07-14 9:10 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: bluez-devel, maxk
In-Reply-To: <20060714080333.GA10043@lst.de>
Hi Christoph,
> > thanks for the patch. It is in my -mh patch now for further testing.
> > What about RFCOMM. No fun in touching that one?
>
> Actually I'm pretty sure I had a patch for that aswell. Unfortunately
> the box I have the kthread patches on doesn't seem to boot currently.
> You'll get the rfcomm patch when I return from Ottawa.
I am releasing a 2.6.17-mh4 before the OLS. You might wanna base it on
that one to avoid merge conflicts. See you in Ottawa.
Regards
Marcel
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
^ permalink raw reply
* Re: [Xenomai-help] Latest rt serial port test program.
From: Jan Kiszka @ 2006-07-14 8:58 UTC (permalink / raw)
To: Kim Chuan Lim; +Cc: xenomai
In-Reply-To: <e325d110607140154r11721be3laf096cf0fde7db02@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 322 bytes --]
Kim Chuan Lim wrote:
> Hi all,
>
> May i know where can i download the latest version of rt serial port
> test program?
> The example program at
> http://www.captain.at/xenomai-serial-port-example.php is a bit too
> old(calling deprecated rt_timer functions).
http://www.rts.uni-hannover.de/rtaddon
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Adding Custom Applications to Damn CD Linux
From: Mukund JB. @ 2006-07-14 8:55 UTC (permalink / raw)
To: linux-newbie
Hi ALL,
I want to build a LIVE_CD Linux dist with Custom application added to
it.
I have an application which I would like to auto-launch from the Damn
Linux Live-CD.
I had experience working with the Linux drivers.
But, I have no experience coming up with my own Live-Cd Linux Dist.
Can some one provide me pointers on doing trhis. i.e. adding Custom
application to Damn Sources and build it on my my Linux BOX.
I am using Dual Boot FC3 and REDHAT 9 Dist's.
DO I need to have a Debian Dist Hosted?
Regards,
Mukund Jampala
-
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
* [Xenomai-help] Latest rt serial port test program.
From: Kim Chuan Lim @ 2006-07-14 8:54 UTC (permalink / raw)
To: xenomai
Hi all,
May i know where can i download the latest version of rt serial port
test program?
The example program at
http://www.captain.at/xenomai-serial-port-example.php is a bit too
old(calling deprecated rt_timer functions).
Regards,
Kim Chuan.
^ permalink raw reply
* Re: [Xenomai-help] RT timer help
From: Jan Kiszka @ 2006-07-14 8:51 UTC (permalink / raw)
To: Kim Chuan Lim; +Cc: xenomai
In-Reply-To: <e325d110607140124s58999affoe349860eeede0de4@domain.hid>
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
Kim Chuan Lim wrote:
> dmesg..
>
> I-pipe: Domain Xenomai registered.
> Xenomai: hal/x86 started.
> Xenomai: real-time nucleus v2.2-rc3 (Engines Of Creation) loaded.
> Xenomai: SMI-enabled chipset found but SMI workaround not enabled (check
> CONFIG_XENO_HW_SMI_WORKAROUND). You may encounter high
> interrupt latencies!
Check the related configuration under Real-time sub-system -> Machine ->
SMI workaround. Switching it on is recommended (but shouldn't be the
reason for the strange timing - but who knows...).
> Xenomai: starting native API services.
> Xenomai: starting POSIX services.
> Xenomai: starting RTDM services.
>
> Pentium 4 3.2GHz with HT.
> My current configuration only able to detect one CPU. :(
Again, HT is EVIL for real-time because it's only pseudo SMP. You cannot
reliably predict when central CPU resources are blocked by any of the
virtual CPUs. Thus, you may suffer from ugly priority inversions between
Linux running on one HT sub-core and Xenomai running on the other, but
both competing for shared resources.
> cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Pentium(R) 4 CPU 3.20GHz
> stepping : 9
> cpu MHz : 3216.093
> cache size : 512 KB
> physical id : 0
> siblings : 1
> core id : 0
> cpu cores : 1
> 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 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe up
> cid xtpr
> bogomips : 6440.74
>
>
> zcat /proc/config.gz
> I have disabled Power Management.
>
> #
> # Power management options (ACPI, APM)
> #
> # CONFIG_PM is not set
>
> #
> # ACPI (Advanced Configuration and Power Interface) Support
> #
> # CONFIG_ACPI is not set
>
> #
> # CPU Frequency scaling
> #
> # CONFIG_CPU_FREQ is not set
>
> Please find the attachment for my /proc/config.gz
>
Some suggestions for tests:
o switch on SMI workaround
o switch off SMP, if that helps, re-enable but leave SCHED_SMT
(hyperthreading) disabled
o switch on ACPI, but leave ACPI_PROCESSOR off
Jan
PS: CONFIG_XENO_OPT_TIMING_PERIODIC is not required unless you really
base your timing on a periodically ticking timer instead of the default
one-shot high-resolution mode. Otherwise this switch only adds overhead.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* Re: SMP share data declaration
From: Jesper Juhl @ 2006-07-14 8:48 UTC (permalink / raw)
To: wyb@topsec.com.cn; +Cc: linux-kernel
In-Reply-To: <002001c6a6f1$74ff85f0$0100000a@codingman>
On 14/07/06, wyb@topsec.com.cn <wyb@topsec.com.cn> wrote:
> I know that an integer variable should be declared volatile to share between
> CPUs.
NO. volatile won't protect you sufficiently.
Use spinlocks, mutexes, semaphores, barriers and the like to protect
variables from concurrent access. Using volatile for this is a BUG and
it won't work correctly.
--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
^ permalink raw reply
* Re: [PATCH]Fixes of performance and stability issues in CFI driver.
From: Alexey Korolev @ 2006-07-14 8:48 UTC (permalink / raw)
To: Nicolas Pitre, dwmw2; +Cc: linux-mtd
In-Reply-To: <Pine.LNX.4.56.0606281918430.15911@pentafluge.infradead.org>
David,
Could you please commit the changes into repository?
I've got mail from Nicolas he found it acceptable.
>
> > Could you please tell me what do you think about this patch? It is not
> > included yet.
>
> It is fine and you can add my sign-off for it.
>
> Sorry for the delay. I was on vacation last week and I am about to have
> some more really soon. In other words I won't have much time for MTD
> stuff until mid august. This includes committing your patch (someone
> else will have to do it).
>
>
> Nicolas
>
> Here is a comment for the patch:
>
> Fix of performance and stability issues on NOR chips. It fixes:
> 1. Very low write performance on Sibley (perf tests demonstrated write performance less than 100Kb/sec when it should be over 400Kb/sec).
> 2. Low erase performance. (perf tests on Sibleuy demonstrated erase performance 246Kb/sec when it should be over 300Kb/sec).
> 3. Error on JFFS2 tests with CPU loading application when MTD returns "block erase error: (status timeout)"
> To fix the issue it does the following:
> 1. Removes the timeout tuning from inval_cache_and_wait_for_operation.
> 2. Waiting conditions in inval_cache_and_wait_for_operation now is based on timer resolution
> If timeout is lower than timer resolution then we do in cycle
> "Checking the status"
> udelay(1);
> cond_resched();
> If timeout is greater than timer resolution (probably erase operation)
> We do the following
> sleep for half of operation timeout
> and do in cycle the following
> "Checking the status"
> sleep for timer resolution
>
> Thanks,
> Alexey
>
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> Signed-off-by: Alexey Korolev <akorolev@infradead.org>
>
> diff -aur orig/drivers/mtd/chips/cfi_cmdset_0001.c latest/drivers/mtd/chips/cfi_cmdset_0001.c
> --- orig/drivers/mtd/chips/cfi_cmdset_0001.c 2006-06-26 13:20:00.000000000 +0400
> +++ latest/drivers/mtd/chips/cfi_cmdset_0001.c 2006-06-28 21:56:09.611390112 +0400
> @@ -908,7 +908,7 @@
>
> static int __xipram xip_wait_for_operation(
> struct map_info *map, struct flchip *chip,
> - unsigned long adr, int *chip_op_time )
> + unsigned long adr, unsigned int chip_op_time )
> {
> struct cfi_private *cfi = map->fldrv_priv;
> struct cfi_pri_intelext *cfip = cfi->cmdset_priv;
> @@ -917,7 +917,7 @@
> flstate_t oldstate, newstate;
>
> start = xip_currtime();
> - usec = *chip_op_time * 8;
> + usec = chip_op_time * 8;
> if (usec == 0)
> usec = 500000;
> done = 0;
> @@ -1027,8 +1027,8 @@
> #define XIP_INVAL_CACHED_RANGE(map, from, size) \
> INVALIDATE_CACHED_RANGE(map, from, size)
>
> -#define INVAL_CACHE_AND_WAIT(map, chip, cmd_adr, inval_adr, inval_len, p_usec) \
> - xip_wait_for_operation(map, chip, cmd_adr, p_usec)
> +#define INVAL_CACHE_AND_WAIT(map, chip, cmd_adr, inval_adr, inval_len, usec) \
> + xip_wait_for_operation(map, chip, cmd_adr, usec)
>
> #else
>
> @@ -1040,64 +1040,64 @@
> static int inval_cache_and_wait_for_operation(
> struct map_info *map, struct flchip *chip,
> unsigned long cmd_adr, unsigned long inval_adr, int inval_len,
> - int *chip_op_time )
> + unsigned int chip_op_time)
> {
> struct cfi_private *cfi = map->fldrv_priv;
> map_word status, status_OK = CMD(0x80);
> - int z, chip_state = chip->state;
> - unsigned long timeo;
> + int chip_state = chip->state;
> + unsigned int timeo, sleep_time;
>
> spin_unlock(chip->mutex);
> if (inval_len)
> INVALIDATE_CACHED_RANGE(map, inval_adr, inval_len);
> - if (*chip_op_time)
> - cfi_udelay(*chip_op_time);
> spin_lock(chip->mutex);
>
> - timeo = *chip_op_time * 8 * HZ / 1000000;
> - if (timeo < HZ/2)
> - timeo = HZ/2;
> - timeo += jiffies;
> + /* set our timeout to 8 times the expected delay */
> + timeo = chip_op_time * 8;
> + if (!timeo)
> + timeo = 500000;
> + sleep_time = chip_op_time / 2;
>
> - z = 0;
> for (;;) {
> - if (chip->state != chip_state) {
> - /* Someone's suspended the operation: sleep */
> - DECLARE_WAITQUEUE(wait, current);
> -
> - set_current_state(TASK_UNINTERRUPTIBLE);
> - add_wait_queue(&chip->wq, &wait);
> - spin_unlock(chip->mutex);
> - schedule();
> - remove_wait_queue(&chip->wq, &wait);
> - timeo = jiffies + (HZ / 2); /* FIXME */
> - spin_lock(chip->mutex);
> - continue;
> - }
> -
> status = map_read(map, cmd_adr);
> if (map_word_andequal(map, status, status_OK, status_OK))
> break;
>
> - /* OK Still waiting */
> - if (time_after(jiffies, timeo)) {
> + if (!timeo) {
> map_write(map, CMD(0x70), cmd_adr);
> chip->state = FL_STATUS;
> return -ETIME;
> }
>
> - /* Latency issues. Drop the lock, wait a while and retry */
> - z++;
> + /* OK Still waiting. Drop the lock, wait a while and retry. */
> spin_unlock(chip->mutex);
> - cfi_udelay(1);
> + if (sleep_time >= 1000000/HZ) {
> + /*
> + * Half of the normal delay still remaining
> + * can be performed with a sleeping delay instead
> + * of busy waiting.
> + */
> + msleep(sleep_time/1000);
> + timeo -= sleep_time;
> + sleep_time = 1000000/HZ;
> + } else {
> + udelay(1);
> + cond_resched();
> + timeo--;
> + }
> spin_lock(chip->mutex);
> - }
>
> - if (!z) {
> - if (!--(*chip_op_time))
> - *chip_op_time = 1;
> - } else if (z > 1)
> - ++(*chip_op_time);
> + if (chip->state != chip_state) {
> + /* Someone's suspended the operation: sleep */
> + DECLARE_WAITQUEUE(wait, current);
> + set_current_state(TASK_UNINTERRUPTIBLE);
> + add_wait_queue(&chip->wq, &wait);
> + spin_unlock(chip->mutex);
> + schedule();
> + remove_wait_queue(&chip->wq, &wait);
> + spin_lock(chip->mutex);
> + }
> + }
>
> /* Done and happy. */
> chip->state = FL_STATUS;
> @@ -1107,8 +1107,7 @@
> #endif
>
> #define WAIT_TIMEOUT(map, chip, adr, udelay) \
> - ({ int __udelay = (udelay); \
> - INVAL_CACHE_AND_WAIT(map, chip, adr, 0, 0, &__udelay); })
> + INVAL_CACHE_AND_WAIT(map, chip, adr, 0, 0, udelay);
>
>
> static int do_point_onechip (struct map_info *map, struct flchip *chip, loff_t adr, size_t len)
> @@ -1332,7 +1331,7 @@
>
> ret = INVAL_CACHE_AND_WAIT(map, chip, adr,
> adr, map_bankwidth(map),
> - &chip->word_write_time);
> + chip->word_write_time);
> if (ret) {
> xip_enable(map, chip, adr);
> printk(KERN_ERR "%s: word write error (status timeout)\n", map->name);
> @@ -1569,7 +1568,7 @@
>
> ret = INVAL_CACHE_AND_WAIT(map, chip, cmd_adr,
> adr, len,
> - &chip->buffer_write_time);
> + chip->buffer_write_time);
> if (ret) {
> map_write(map, CMD(0x70), cmd_adr);
> chip->state = FL_STATUS;
> @@ -1704,7 +1703,7 @@
>
> ret = INVAL_CACHE_AND_WAIT(map, chip, adr,
> adr, len,
> - &chip->erase_time);
> + chip->erase_time);
> if (ret) {
> map_write(map, CMD(0x70), adr);
> chip->state = FL_STATUS;
>
Thanks,
Alexey
^ permalink raw reply
* [U-Boot-Users] skipping bad blocks when erasing nand
From: Stefan Roese @ 2006-07-14 8:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060714082857.CE206352681@atlas.denx.de>
Hello Wolfgang,
On Friday 14 July 2006 10:28, Wolfgang Denk wrote:
> in message <200607140914.07427.sr@denx.de> you wrote:
> > I am "voting" for David's implementation, since bad blocks are "normal"
> > on NAND chips. And if I remember correctly, the "old" U-Boot NAND driver
> > also just skipped the bad block upon erasing without reproting them.
>
> I'm sorry, but I disagree. This code is not coming out of thin air.
> It is a more or less vrbatim copy of the corresponding Linux MTD NAND
> code, see "drivers/mtd/nand/nand_base.c" in your Linux kernel tree.
>
> In U-Boot, we have the additional #define NAND_ALLOW_ERASE_ALL which
> can be enabled if you don't like this behaviour.
>
> If you believe that the U-Boot behavious is wrong, then the Linux MTD
> driver would be wrong, too. In this case discussion should continue
> on the MTD mailing list.
I find it hard to believe that a linux NAND erase operation will stop upon
reaching a bad block. But you are right: the code in question is the same in
the current linux mtd driver. From my experience, I never had problems
erasing NAND flash devices (from U-Boot & linux) which had bad blocks.
> As long as I don't see any changes to the current MTD Linux code you
> will need really good arguments to talk me into changing the U-Boot
> code.
I see. You have a good point here. This needs some testing on a device with
bad blocks. "Unfortunately" the device on my desk has no bad blocks at all:
=> nand bad
Device 0 bad blocks:
Perhaps somebody else can jump in here and test the current linux mtd driver
behavior on a device with bad blocks. Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] USB: removed a unbalanced #endif from ohci-au1xxx.c
From: Domen Puncer @ 2006-07-14 8:45 UTC (permalink / raw)
To: Yoichi Yuasa; +Cc: linux-usb-devel, linux-mips, Daniel Mack
In-Reply-To: <20060714162935.70502a98.yoichi_yuasa@tripeaks.co.jp>
On 14/07/06 16:29 +0900, Yoichi Yuasa wrote:
> Hi,
>
> This patch has removed a unbalanced #endif from ohci-au1xxx.c .
>
> Error message was:
> In file included from drivers/usb/host/ohci-hcd.c:909:
> drivers/usb/host/ohci-au1xxx.c:113:2: #endif without #if
>
> Yoichi
>
> Signed-off-by: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
>
> diff -pruN -X 2.6.18-rc1/Documentation/dontdiff 2.6.18-rc1-orig/drivers/usb/host/ohci-au1xxx.c 2.6.18-rc1/drivers/usb/host/ohci-au1xxx.c
> --- 2.6.18-rc1-orig/drivers/usb/host/ohci-au1xxx.c 2006-07-14 11:17:34.443211500 +0900
> +++ 2.6.18-rc1/drivers/usb/host/ohci-au1xxx.c 2006-07-14 10:33:47.945949750 +0900
> @@ -110,7 +110,6 @@ static void au1xxx_start_ohc(struct plat
>
> printk(KERN_DEBUG __FILE__
> ": Clock to USB host has been enabled \n");
> -#endif
> }
>
> static void au1xxx_stop_ohc(struct platform_device *dev)
Looks right to me.
It looks like something went wrong with this patch
http://www.linux-mips.org/git?p=linux.git;a=commitdiff;h=d14feb5ee4a46218f92b21ed52338b64130a151b
Looks like ehci-au1xxx.c might also be affected.
Daniel?
Domen
^ permalink raw reply
* Re: [JOB] Senior Embedded Linux Video Engineer
From: Stephen Rothwell @ 2006-07-14 8:43 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, RichardDavenport
In-Reply-To: <20060714080754.GA10177@lst.de>
[-- Attachment #1: Type: text/plain, Size: 389 bytes --]
On Fri, 14 Jul 2006 10:07:54 +0200 Christoph Hellwig <hch@lst.de> wrote:
>
> Please stop spamming people, especially on public mailinglists.
Richard asked the list admins before he sent this message and we decided
it would be OK if he identifed the message in its subject.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [patch -mm] s390: kprobes compile fix
From: Heiko Carstens @ 2006-07-14 8:39 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, bibo.mao, Michael Grundy, Martin Schwidefsky
In-Reply-To: <20060713224800.6cbdbf5d.akpm@osdl.org>
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Add missing flush_insn_slot define to let kprobes compile on s390.
Cc: bibo,mao <bibo.mao@intel.com>
Cc: Michael Grundy <grundym@us.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
ia64-kprobe-invalidate-icache-of-jump-buffer.patch breaks kprobes on s390
which comes with git-s390.patch.
include/asm-s390/kprobes.h | 3 +++
1 files changed, 3 insertions(+)
diff -purN a/include/asm-s390/kprobes.h b/include/asm-s390/kprobes.h
--- a/include/asm-s390/kprobes.h 2006-07-14 10:33:40.000000000 +0200
+++ b/include/asm-s390/kprobes.h 2006-07-14 10:28:48.000000000 +0200
@@ -96,6 +96,9 @@ void arch_remove_kprobe(struct kprobe *p
void kretprobe_trampoline(void);
int is_prohibited_opcode(kprobe_opcode_t *instruction);
void get_instruction_type(struct arch_specific_insn *ainsn);
+
+#define flush_insn_slot(p) do { } while (0)
+
#endif /* _ASM_S390_KPROBES_H */
#ifdef CONFIG_KPROBES
^ 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.