[PATCH] introduce fallocate support into xfs_io
FYI.
Initial support for fallocate-based pre-allocation in
xfs_io for testing. This currently only works on ia64 because
of the hard coded syscall number and will require autoconf
magic to conditionally compile in this support.
This allows simple command-line based testing of fallocate
based allocation such as:
# ~/xfs_io -f -c "falloc_resvsp 0 1024k" -c "bmap -vp" -c stat /mnt/scratch/fred
/mnt/scratch/fred:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSETTOTAL FLAGS
0: [0..2047]: 96..2143 0 (96..2143)2048 1
fd.path = "/mnt/scratch/fred"
fd.flags = non-sync,non-direct,read-write
stat.ino = 131
stat.type = regular file
stat.size = 0
stat.blocks = 2048
fsxattr.xflags = 0x2 [-p]
fsxattr.projid = 0
fsxattr.extsize = 0
fsxattr.nextents = 1
fsxattr.naextents = 0
dioattr.mem = 0x200
dioattr.miniosz = 512
dioattr.maxiosz = 2147483136
Or more complex cases:
# ~/xfs_io -f \
> -c "falloc_allocsp 0 1024k" \
> -c "unresvsp 32k 32k" \
> -c "unresvsp 128k 64k" \
> -c "unresvsp 512k 256k" \
> -c"pwrite 0 16k" \
> -c "pwrite 96k 128k" \
> -c "pwrite 640k 384k" \
> -c "bmap -vp" \
> -c "falloc_resvsp 0 1024k" \
> -c "bmap -vvp" /mnt/scratch/fred
wrote 16384/16384 bytes at offset 0
16 KiB, 4 ops; 0. sec (274.123 MiB/sec and 70175.4386 ops/sec)
wrote 131072/131072 bytes at offset 98304
128 KiB, 32 ops; 0. sec (338.753 MiB/sec and 86720.8672 ops/sec)
wrote 393216/393216 bytes at offset 655360
384 KiB, 96 ops; 0. sec (386.200 MiB/sec and 98867.1473 ops/sec)
/mnt/scratch/fred:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSETTOTAL FLAGS
0: [0..31]: 96..127 0 (96..127) 32
1: [32..63]:128..159 0 (128..159) 32 1
2: [64..127]: hole64
3: [128..191]: 224..287 0 (224..287) 64 1
4: [192..447]: 288..543 0 (288..543) 256
5: [448..1023]: 544..1119 0 (544..1119)576 1
6: [1024..1279]:hole 256
7: [1280..2047]:1376..21430 (1376..2143) 768
/mnt/scratch/fred:
EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSETTOTAL FLAGS
0: [0..31]: 96..127 0 (96..127) 32
1: [32..191]: 128..287 0 (128..287) 160 1
2: [192..447]: 288..543 0 (288..543) 256
3: [448..1279]: 544..1375 0 (544..1375)832 1
4: [1280..2047]:1376..21430 (1376..2143) 768
FLAG Values:
01 Unwritten preallocated extent
001000 Doesn't begin on stripe unit
000100 Doesn't end on stripe unit
10 Doesn't begin on stripe width
01 Doesn't end on stripe width
Yes, that looks like it filled all the holes properly, and the allocator
allocated the right holes on disk to merge adjacent extents when hole
filling. ;)
---
xfsprogs/io/prealloc.c | 72 +
1 file changed, 72 insertions(+)
Index: xfs-cmds/xfsprogs/io/prealloc.c
===
--- xfs-cmds.orig/xfsprogs/io/prealloc.c2006-11-15 19:00:31.0
+1100
+++ xfs-cmds/xfsprogs/io/prealloc.c 2007-07-16 15:25:44.041513574 +1000
@@ -26,6 +26,8 @@ static cmdinfo_t allocsp_cmd;
static cmdinfo_t freesp_cmd;
static cmdinfo_t resvsp_cmd;
static cmdinfo_t unresvsp_cmd;
+static cmdinfo_t falloc_allocsp_cmd;
+static cmdinfo_t falloc_resvsp_cmd;
static int
offset_length(
@@ -119,6 +121,56 @@ unresvsp_f(
return 0;
}
+/*
+ * Hack, hack, hackety-hack-hack.
+ *
+ * This only works for ia64...
+ */
+#define __NR_fallocate1303
+
+/*
+ * someday there'll be a real header file
+ */
+#define FALLOC_FL_KEEP_SIZE 0x01
+#define FALLOC_ALLOCATE 0x0
+#define FALLOC_RESV_SPACE FALLOC_FL_KEEP_SIZE
+
+static int
+fallocate_allocsp_f(
+ int argc,
+ char**argv)
+{
+ xfs_flock64_t segment;
+
+ if (!offset_length(argv[1], argv[2], ))
+ return 0;
+
+ if (syscall(__NR_fallocate, file->fd, FALLOC_ALLOCATE,
+ segment.l_start, segment.l_len)) {
+ perror("FALLOC_ALLOCATE");
+ return 0;
+ }
+ return 0;
+}
+
+static int
+fallocate_resvsp_f(
+ int argc,
+ char**argv)
+{
+ xfs_flock64_t segment;
+
+ if (!offset_length(argv[1], argv[2], ))
+ return 0;
+
+ if (syscall(__NR_fallocate, file->fd, FALLOC_RESV_SPACE,
+ segment.l_start, segment.l_len)) {
+ perror("FALLOC_ALLOCATE");
+ return 0;
+ }
+ return 0;
+}
+
void
prealloc_init(void)
{
@@ -156,8 +208,28 @@ prealloc_init(void)
unresvsp_cmd.oneline =
_("frees reserved space associated
[PATCH] xfs: implement fallocate V2
Initial implementation of ->fallocate for XFS.
Version 2:
o Make allocation and setting the file size atomic.
o Drop deallocate/punch functionality
o use mode field appropriately to determine if size needs changing.
---
fs/xfs/linux-2.6/xfs_iops.c | 47
1 file changed, 47 insertions(+)
Index: 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c
===
--- 2.6.x-xfs-new.orig/fs/xfs/linux-2.6/xfs_iops.c 2007-07-16
14:16:02.090255611 +1000
+++ 2.6.x-xfs-new/fs/xfs/linux-2.6/xfs_iops.c 2007-07-16 14:50:07.087885337
+1000
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Get a XFS inode from a given vnode.
@@ -812,6 +813,51 @@ xfs_vn_removexattr(
return namesp->attr_remove(vp, attr, xflags);
}
+/*
+ * generic space allocation vector.
+ *
+ * This should really through a bhv_vop before stuffing around
+ * with xfs_inodes and such.
+ */
+STATIC long
+xfs_vn_fallocate(
+ struct inode*inode,
+ int mode,
+ loff_t offset,
+ loff_t len)
+{
+ longerror = -EOPNOTSUPP;
+ bhv_vnode_t *vp = vn_from_inode(inode);
+ bhv_desc_t *bdp;
+ loff_t new_size = 0;
+ xfs_flock64_t bf;
+
+ bf.l_whence = 0;
+ bf.l_start = offset;
+ bf.l_len = len;
+
+ bdp = bhv_lookup_range(VN_BHV_HEAD(vp), VNODE_POSITION_XFS,
+ VNODE_POSITION_XFS);
+
+ xfs_ilock(xfs_vtoi(vp), XFS_IOLOCK_EXCL);
+ error = xfs_change_file_space(bdp, XFS_IOC_RESVSP, , 0, NULL,
+ ATTR_NOLOCK);
+ if (!error && !(mode & FALLOC_FL_KEEP_SIZE) &&
+ offset + len > i_size_read(inode))
+ new_size = offset + len;
+
+ /* Change file size if needed */
+ if (new_size) {
+ bhv_vattr_t va;
+
+ va.va_mask = XFS_AT_SIZE;
+ va.va_size = new_size;
+ error = bhv_vop_setattr(vp, , ATTR_NOLOCK, NULL);
+ }
+
+ xfs_iunlock(xfs_vtoi(vp), XFS_IOLOCK_EXCL);
+ return error;
+}
const struct inode_operations xfs_inode_operations = {
.permission = xfs_vn_permission,
@@ -822,6 +868,7 @@ const struct inode_operations xfs_inode_
.getxattr = xfs_vn_getxattr,
.listxattr = xfs_vn_listxattr,
.removexattr= xfs_vn_removexattr,
+ .fallocate = xfs_vn_fallocate,
};
const struct inode_operations xfs_dir_inode_operations = {
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernating To Swap Considered Harmful
On Sat, Jul 14, 2007 at 11:48:17AM +0200, Rafael J. Wysocki wrote: > On Saturday, 14 July 2007 02:45, Joseph Fannin wrote: > > On Fri, Jul 13, 2007 at 11:30:50AM +0200, Rafael J. Wysocki wrote: > > > On Friday, 13 July 2007 07:42, Joseph Fannin wrote: > > > > On Thu, Jul 12, 2007 at 08:06:43PM -0700, [EMAIL PROTECTED] wrote: > > > > > > If you're afraid of that, use a dedicated swap file. > > > > I don't understand what you mean. A dedicated swap file for what? > > Sorry, I should have been more precise. > > For hibernation (ie. a swap file that you activate right befor the > hibernation). > > Also tuxonice (formerly known as suspend2) allows you to use regular files > hibernation. How is that different from what I proposed, other than the requirement to pass the swap data stuctures between the two kernels? Even if you only expect hibernation to work only _most of the time_, suspending to swap means allocating a bunch of swap space that you intend to never be used as swap. The two functions don't really belong together. -- Joseph Fannin [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ia64 fallocate system call
sys_fallocate for ia64. This uses the empty slot originally reserved for move_pages. Signed-Off-By: Dave Chinner <[EMAIL PROTECTED]> --- arch/ia64/kernel/entry.S |2 +- include/asm-ia64/unistd.h |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: 2.6.x-xfs-new/arch/ia64/kernel/entry.S === --- 2.6.x-xfs-new.orig/arch/ia64/kernel/entry.S 2007-07-16 14:18:51.432168485 +1000 +++ 2.6.x-xfs-new/arch/ia64/kernel/entry.S 2007-07-16 14:22:08.582454284 +1000 @@ -1581,7 +1581,7 @@ sys_call_table: data8 sys_sync_file_range // 1300 data8 sys_tee data8 sys_vmsplice - data8 sys_ni_syscall// reserved for move_pages + data8 sys_fallocate data8 sys_getcpu data8 sys_epoll_pwait // 1305 data8 sys_utimensat Index: 2.6.x-xfs-new/include/asm-ia64/unistd.h === --- 2.6.x-xfs-new.orig/include/asm-ia64/unistd.h2007-06-08 21:36:31.0 +1000 +++ 2.6.x-xfs-new/include/asm-ia64/unistd.h 2007-07-16 14:22:41.166204402 +1000 @@ -292,7 +292,7 @@ #define __NR_sync_file_range 1300 #define __NR_tee 1301 #define __NR_vmsplice 1302 -/* 1303 reserved for move_pages */ +#define __NR_fallocate 1303 #define __NR_getcpu1304 #define __NR_epoll_pwait 1305 #define __NR_utimensat 1306 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6][TAKE7] manpage for fallocate
On Sat, Jul 14, 2007 at 10:23:42AM +0200, Michael Kerrisk wrote: > [CC += [EMAIL PROTECTED] > > Amit, Hi Michael, > Thanks for this page. I will endeavour to review it in > the coming days. In the meantime, the better address to CC > me on fot man pages stuff is [EMAIL PROTECTED] Sure. BTW, this man page has changed a bit and the one in TAKE8 of fallocate patches is the latest one. You are copied on that too. I will forward that mail to "[EMAIL PROTECTED]" id also, so that you do not miss it. Thanks! -- Regards, Amit Arora > > Cheers, > > Michael > > > Following is the modified version of the manpage originally submitted by > > David Chinner. Please use `nroff -man fallocate.2 | less` to view. > > > > This includes changes suggested by Heikki Orsila and Barry Naujok. > > > > > > .TH fallocate 2 > > .SH NAME > > fallocate \- allocate or remove file space > > .SH SYNOPSIS > > .nf > > .B #include > > .PP > > .BI "long fallocate(int " fd ", int " mode ", loff_t " offset ", loff_t " > > len); > > .SH DESCRIPTION > > The > > .B fallocate > > syscall allows a user to directly manipulate the allocated disk space > > for the file referred to by > > .I fd > > for the byte range starting at > > .I offset > > and continuing for > > .I len > > bytes. > > The > > .I mode > > parameter determines the operation to be performed on the given range. > > Currently there are two modes: > > .TP > > .B FALLOC_ALLOCATE > > allocates and initialises to zero the disk space within the given range. > > After a successful call, subsequent writes are guaranteed not to fail > > because > > of lack of disk space. If the size of the file is less than > > .IR offset + len , > > then the file is increased to this size; otherwise the file size is left > > unchanged. > > .B FALLOC_ALLOCATE > > closely resembles > > .BR posix_fallocate (3) > > and is intended as a method of optimally implementing this function. > > .B FALLOC_ALLOCATE > > may allocate a larger range than that was specified. > > .TP > > .B FALLOC_RESV_SPACE > > provides the same functionality as > > .B FALLOC_ALLOCATE > > except it does not ever change the file size. This allows allocation > > of zero blocks beyond the end of file and is useful for optimising > > append workloads. > > .SH RETURN VALUE > > .B fallocate > > returns zero on success, or an error number on failure. > > Note that > > .I errno > > is not set. > > .SH ERRORS > > .TP > > .B EBADF > > .I fd > > is not a valid file descriptor, or is not opened for writing. > > .TP > > .B EFBIG > > .IR offset + len > > exceeds the maximum file size. > > .TP > > .B EINVAL > > .I offset > > was less than 0, or > > .I len > > was less than or equal to 0. > > .TP > > .B ENODEV > > .I fd > > does not refer to a regular file or a directory. > > .TP > > .B ENOSPC > > There is not enough space left on the device containing the file > > referred to by > > .IR fd . > > .TP > > .B ESPIPE > > .I fd > > refers to a pipe of file descriptor. > > .TP > > .B ENOSYS > > The filesystem underlying the file descriptor does not support this > > operation. > > .TP > > .B EINTR > > A signal was caught during execution > > .TP > > .B EIO > > An I/O error occurred while reading from or writing to a file system. > > .TP > > .B EOPNOTSUPP > > The mode is not supported on the file descriptor. > > .SH AVAILABILITY > > The > > .B fallocate > > system call is available since 2.6.XX > > .SH SEE ALSO > > .BR syscall (2), > > .BR posix_fadvise (3), > > .BR ftruncate (3). > > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/7] HiSax hfc_pci: minor cleanups
commit 163fc2ed7352b93cedb02af8a7a766c0b9bb475f
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 21:48:07 2007 -0400
[ISDN] HiSax hfc_pci: minor cleanups
* trim trailing whitespace
* remove CONFIG_PCI ifdefs, this driver is always PCI (Kconfig enforced)
* remove return statements at the tail of a function
* remove indentation levels by returning an error code immediately.
Makes the code much more readable, and easier to update to PCI hotplug
API.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/hfc_pci.c | 191 ---
1 file changed, 93 insertions(+), 98 deletions(-)
163fc2ed7352b93cedb02af8a7a766c0b9bb475f
diff --git a/drivers/isdn/hisax/hfc_pci.c b/drivers/isdn/hisax/hfc_pci.c
index 8a48a3c..077080a 100644
--- a/drivers/isdn/hisax/hfc_pci.c
+++ b/drivers/isdn/hisax/hfc_pci.c
@@ -6,7 +6,7 @@
* based on existing driver for CCD hfc ISA cards
* Copyrightby Werner Cornelius <[EMAIL PROTECTED]>
* by Karsten Keil <[EMAIL PROTECTED]>
- *
+ *
* This software may be used and distributed according to the terms
* of the GNU General Public License, incorporated herein by reference.
*
@@ -67,8 +67,6 @@ static const PCI_ENTRY id_list[] =
};
-#ifdef CONFIG_PCI
-
/**/
/* free hardware resources used by driver */
/**/
@@ -237,7 +235,7 @@ static void hfcpci_clear_fifo_rx(struct IsdnCardState *cs,
int fifo)
if (fifo_state)
cs->hw.hfcpci.fifo_en |= fifo_state;
Write_hfc(cs, HFCPCI_FIFO_EN, cs->hw.hfcpci.fifo_en);
-}
+}
/***/
/* clear the desired B-channel tx fifo */
@@ -263,7 +261,7 @@ static void hfcpci_clear_fifo_tx(struct IsdnCardState *cs,
int fifo)
if (fifo_state)
cs->hw.hfcpci.fifo_en |= fifo_state;
Write_hfc(cs, HFCPCI_FIFO_EN, cs->hw.hfcpci.fifo_en);
-}
+}
/*/
/* read a complete B-frame out of the buffer */
@@ -511,7 +509,6 @@ main_rec_hfcpci(struct BCState *bcs)
test_and_clear_bit(FLG_LOCK_ATOMIC, >HW_Flags);
if (count && receive)
goto Begin;
- return;
}
/**/
@@ -582,7 +579,6 @@ hfcpci_fill_dfifo(struct IsdnCardState *cs)
dev_kfree_skb_any(cs->tx_skb);
cs->tx_skb = NULL;
- return;
}
/**/
@@ -729,7 +725,6 @@ hfcpci_fill_fifo(struct BCState *bcs)
dev_kfree_skb_any(bcs->tx_skb);
bcs->tx_skb = NULL;
test_and_clear_bit(BC_FLG_BUSY, >Flag);
- return;
}
/**/
@@ -924,7 +919,6 @@ receive_emsg(struct IsdnCardState *cs)
test_and_clear_bit(FLG_LOCK_ATOMIC, >HW_Flags);
if (count && receive)
goto Begin;
- return;
} /* receive_emsg */
/*/
@@ -1350,13 +1344,13 @@ mode_hfcpci(struct BCState *bcs, int mode, int bc)
cs->hw.hfcpci.sctrl_r |= SCTRL_B1_ENA;
}
if (fifo2) {
- cs->hw.hfcpci.last_bfifo_cnt[1] = 0;
+ cs->hw.hfcpci.last_bfifo_cnt[1] = 0;
cs->hw.hfcpci.fifo_en |= HFCPCI_FIFOEN_B2;
cs->hw.hfcpci.int_m1 |= (HFCPCI_INTS_B2TRANS +
HFCPCI_INTS_B2REC);
cs->hw.hfcpci.ctmt &= ~2;
cs->hw.hfcpci.conn &= ~0x18;
} else {
- cs->hw.hfcpci.last_bfifo_cnt[0] = 0;
+ cs->hw.hfcpci.last_bfifo_cnt[0] = 0;
cs->hw.hfcpci.fifo_en |= HFCPCI_FIFOEN_B1;
cs->hw.hfcpci.int_m1 |= (HFCPCI_INTS_B1TRANS +
HFCPCI_INTS_B1REC);
cs->hw.hfcpci.ctmt &= ~1;
@@ -1642,8 +1636,6 @@ hfcpci_card_msg(struct IsdnCardState *cs, int mt, void
*arg)
/* this variable is used as card index when more than one cards are present */
static struct pci_dev *dev_hfcpci __devinitdata = NULL;
-#endif /* CONFIG_PCI */
-
int __devinit
setup_hfcpci(struct IsdnCard *card)
{
@@ -1656,96 +1648,99 @@ setup_hfcpci(struct IsdnCard *card)
#ifdef __BIG_ENDIAN
#error "not running on big endian machines now"
#endif
+
strcpy(tmp, hfcpci_revision);
printk(KERN_INFO "HiSax: HFC-PCI driver Rev. %s\n", HiSax_getrev(tmp));
-#ifdef CONFIG_PCI
+
cs->hw.hfcpci.int_s1 = 0;
cs->dc.hfcpci.ph_state = 0;
cs->hw.hfcpci.fifo = 255;
- if (cs->typ == ISDN_CTYPE_HFC_PCI) {
- i = 0;
- while (id_list[i].vendor_id) {
- tmp_hfcpci =
[PATCH 7/7] HiSax hfc_pci: convert to PCI hotplug API
commit 823d1521c1059611542f60f55318422e9a47982f
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 22:12:35 2007 -0400
[ISDN] HiSax: convert hfc_pci driver to PCI hotplug API
Also, mark several setup functions in other already-converted drivers
static.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/Kconfig|2
drivers/isdn/hisax/Makefile |2
drivers/isdn/hisax/bkm_a4t.c |2
drivers/isdn/hisax/config.c | 44 ---
drivers/isdn/hisax/enternow_pci.c |2
drivers/isdn/hisax/hfc_pci.c | 142 +-
drivers/isdn/hisax/nj_u.c |2
drivers/isdn/hisax/w6692.c|2
8 files changed, 118 insertions(+), 80 deletions(-)
823d1521c1059611542f60f55318422e9a47982f
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index 03e4ea5..aa3ba1d 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -316,7 +316,7 @@ config HISAX_GAZEL
settings.
config HISAX_HFC_PCI
- bool "HFC PCI-Bus cards"
+ tristate "HFC PCI-Bus cards"
depends on PCI && (BROKEN || !(SPARC || PPC || PARISC || M68K || (MIPS
&& !CPU_LITTLE_ENDIAN) || FRV))
help
This enables HiSax support for the HFC-S PCI 2BDS0 based cards.
diff --git a/drivers/isdn/hisax/Makefile b/drivers/isdn/hisax/Makefile
index 1f02120..d1b543c 100644
--- a/drivers/isdn/hisax/Makefile
+++ b/drivers/isdn/hisax/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_HISAX_NETJET_U) += netjet_u.o libhisax.o
obj-$(CONFIG_HISAX_ENTERNOW_PCI) += enternow.o libhisax.o
obj-$(CONFIG_HISAX_BKM_A4T)+= bkm_a4t_pci.o libhisax.o
obj-$(CONFIG_HISAX_W6692) += w6692.o libhisax.o
+obj-$(CONFIG_HISAX_HFC_PCI)+= hfc_pci.o libhisax.o
bkm_a4t_pci-objs := bkm_a4t.o jade.o
enternow-objs := enternow_pci.o amd7930_fn.o
@@ -58,7 +59,6 @@ hisax-$(CONFIG_HISAX_SEDLBAUER) += sedlbauer.o
hscx.o isar.o
hisax-$(CONFIG_HISAX_SPORTSTER)+= sportster.o hscx.o
hisax-$(CONFIG_HISAX_MIC) += mic.o hscx.o
hisax-$(CONFIG_HISAX_HFCS) += hfcscard.o hfc_2bds0.o
-hisax-$(CONFIG_HISAX_HFC_PCI) += hfc_pci.o
hisax-$(CONFIG_HISAX_HFC_SX) += hfc_sx.o
hisax-$(CONFIG_HISAX_NICCY)+= niccy.o hscx.o
hisax-$(CONFIG_HISAX_ISURF)+= isurf.o sar.o
diff --git a/drivers/isdn/hisax/bkm_a4t.c b/drivers/isdn/hisax/bkm_a4t.c
index 918afb3..627547f 100644
--- a/drivers/isdn/hisax/bkm_a4t.c
+++ b/drivers/isdn/hisax/bkm_a4t.c
@@ -321,7 +321,7 @@ static int __devinit a4t_cs_init(struct IsdnCard *card,
return (1);
}
-int __devinit
+static int __devinit
setup_bkm_a4t(struct IsdnCard *card)
{
struct IsdnCardState *cs = card->cs;
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index 163a636..3960233 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -208,13 +208,6 @@ const char *CardType[] = {
#define DEFAULT_CFG {5,0x500,0,0}
#endif
-#ifdef CONFIG_HISAX_HFC_PCI
-#undef DEFAULT_CARD
-#undef DEFAULT_CFG
-#define DEFAULT_CARD ISDN_CTYPE_HFC_PCI
-#define DEFAULT_CFG {0,0,0,0}
-#endif
-
#ifdef CONFIG_HISAX_HFC_SX
#undef DEFAULT_CARD
#undef DEFAULT_CFG
@@ -479,10 +472,6 @@ extern int setup_mic(struct IsdnCard *card);
extern int setup_hfcs(struct IsdnCard *card);
#endif
-#if CARD_HFC_PCI
-extern int setup_hfcpci(struct IsdnCard *card);
-#endif
-
#if CARD_HFC_SX
extern int setup_hfcsx(struct IsdnCard *card);
#endif
@@ -876,11 +865,6 @@ static int hisax_cs_setup_card(struct IsdnCard *card)
ret = setup_hfcs(card);
break;
#endif
-#if CARD_HFC_PCI
- case ISDN_CTYPE_HFC_PCI:
- ret = setup_hfcpci(card);
- break;
-#endif
#if CARD_HFC_SX
case ISDN_CTYPE_HFC_SX:
ret = setup_hfcsx(card);
@@ -921,6 +905,7 @@ static int hisax_cs_setup_card(struct IsdnCard *card)
case ISDN_CTYPE_ENTERNOW:
case ISDN_CTYPE_BKM_A4T:
case ISDN_CTYPE_W6692:
+ case ISDN_CTYPE_HFC_PCI:
printk(KERN_WARNING "HiSax: Support for %s Card has moved "
"to separate PCI driver module\n",
CardType[card->typ]);
@@ -1346,7 +1331,6 @@ static int __init HiSax_init(void)
break;
#endif
case ISDN_CTYPE_ELSA:
- case ISDN_CTYPE_HFC_PCI:
cards[j].para[0] = io[i];
break;
case ISDN_CTYPE_16_3:
@@ -1390,6 +1374,7 @@ static int __init HiSax_init(void)
case ISDN_CTYPE_ENTERNOW:
case ISDN_CTYPE_BKM_A4T:
case ISDN_CTYPE_W6692:
+ case ISDN_CTYPE_HFC_PCI:
break;
case ISDN_CTYPE_SCT_QUADRO:
@@ -1523,6 +1508,7
[PATCH 4/7] HiSax bkm_a4t: convert to PCI hotplug API
commit 9e435c5da75f6edead09e1acd9b2f441e16a539d
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 20:26:37 2007 -0400
[ISDN] HiSax: convert bkm_a4t to PCI hotplug API
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/Kconfig |2
drivers/isdn/hisax/Makefile |3 -
drivers/isdn/hisax/bkm_a4t.c | 118 ---
drivers/isdn/hisax/config.c | 20 ---
4 files changed, 83 insertions(+), 60 deletions(-)
9e435c5da75f6edead09e1acd9b2f441e16a539d
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index 7de6fda..b04503d 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -287,7 +287,7 @@ config HISAX_HSTSAPHIR
settings.
config HISAX_BKM_A4T
- bool "Telekom A4T card"
+ tristate "Telekom A4T card"
depends on PCI
help
This enables HiSax support for the Telekom A4T card.
diff --git a/drivers/isdn/hisax/Makefile b/drivers/isdn/hisax/Makefile
index db5580b..e63e2af 100644
--- a/drivers/isdn/hisax/Makefile
+++ b/drivers/isdn/hisax/Makefile
@@ -18,7 +18,9 @@ obj-$(CONFIG_HISAX_FRITZ_PCIPNP)+= hisax_isac.o
hisax_fcpcipnp.o
obj-$(CONFIG_HISAX_NETJET) += netjet_s.o libhisax.o
obj-$(CONFIG_HISAX_NETJET_U) += netjet_u.o libhisax.o
obj-$(CONFIG_HISAX_ENTERNOW_PCI) += enternow.o libhisax.o
+obj-$(CONFIG_HISAX_BKM_A4T)+= bkm_a4t_pci.o
+bkm_a4t_pci-objs := bkm_a4t.o jade.o
enternow-objs := enternow_pci.o amd7930_fn.o
netjet_s-objs := nj_s.o
netjet_u-objs := nj_u.o icc.o
@@ -60,7 +62,6 @@ hisax-$(CONFIG_HISAX_HFC_SX) += hfc_sx.o
hisax-$(CONFIG_HISAX_NICCY)+= niccy.o hscx.o
hisax-$(CONFIG_HISAX_ISURF)+= isurf.o sar.o
hisax-$(CONFIG_HISAX_HSTSAPHIR)+= saphir.o hscx.o
-hisax-$(CONFIG_HISAX_BKM_A4T) += bkm_a4t.o jade.o
hisax-$(CONFIG_HISAX_SCT_QUADRO) += bkm_a8.o hscx.o
hisax-$(CONFIG_HISAX_GAZEL)+= gazel.o hscx.o
hisax-$(CONFIG_HISAX_W6692)+= w6692.o
diff --git a/drivers/isdn/hisax/bkm_a4t.c b/drivers/isdn/hisax/bkm_a4t.c
index 3d1bdc8..918afb3 100644
--- a/drivers/isdn/hisax/bkm_a4t.c
+++ b/drivers/isdn/hisax/bkm_a4t.c
@@ -13,6 +13,7 @@
#include
#include "hisax.h"
+#include "hisax_proto.h"
#include "isac.h"
#include "hscx.h"
#include "jade.h"
@@ -20,7 +21,7 @@
#include
#include "bkm_ax.h"
-extern const char *CardType[];
+static int a4t_protocol; /* 0 == use DEFAULT_PROTO */
static const char *bkm_a4t_revision = "$Revision: 1.22.2.4 $";
@@ -257,24 +258,21 @@ BKM_card_msg(struct IsdnCardState *cs, int mt, void *arg)
static int __devinit a4t_pci_probe(struct pci_dev *dev_a4t,
struct IsdnCardState *cs,
- u_int *found,
u_int *pci_memaddr)
{
- u16 sub_sys;
- u16 sub_vendor;
-
- sub_vendor = dev_a4t->subsystem_vendor;
- sub_sys = dev_a4t->subsystem_device;
- if ((sub_sys == PCI_DEVICE_ID_BERKOM_A4T) && (sub_vendor ==
PCI_VENDOR_ID_BERKOM)) {
- if (pci_enable_device(dev_a4t))
- return (0); /* end loop & function */
- *found = 1;
- *pci_memaddr = pci_resource_start(dev_a4t, 0);
- cs->irq = dev_a4t->irq;
- return (1); /* end loop */
+ if (pci_enable_device(dev_a4t))
+ return (0); /* error */
+
+ *pci_memaddr = pci_resource_start(dev_a4t, 0);
+ if (!(*pci_memaddr)) {
+ printk(KERN_WARNING "HiSax bkm_a4t: No Memory base address\n");
+ return (0);
}
- return (-1);/* continue looping */
+ cs->irq = dev_a4t->irq;
+
+ cs->hw.ax.dev = dev_a4t;
+ return (1); /* success */
}
static int __devinit a4t_cs_init(struct IsdnCard *card,
@@ -284,7 +282,7 @@ static int __devinit a4t_cs_init(struct IsdnCard *card,
I20_REGISTER_FILE *pI20_Regs;
if (!cs->irq) { /* IRQ range check ?? */
- printk(KERN_WARNING "HiSax: %s: No IRQ\n", CardType[card->typ]);
+ printk(KERN_WARNING "HiSax: bkm_a4t: No IRQ\n");
return (0);
}
cs->hw.ax.base = (long) ioremap(pci_memaddr, 4096);
@@ -292,7 +290,7 @@ static int __devinit a4t_cs_init(struct IsdnCard *card,
pI20_Regs = (I20_REGISTER_FILE *) (cs->hw.ax.base);
if ((pI20_Regs->i20IntStatus & 0x8EFF) != 0) {
printk(KERN_WARNING "HiSax: %s address %lx-%lx suspecious\n",
- CardType[card->typ], cs->hw.ax.base, cs->hw.ax.base +
4096);
+ "bkm_a4t", cs->hw.ax.base, cs->hw.ax.base + 4096);
iounmap((void *) cs->hw.ax.base);
[PATCH 5/7] HiSax w6692: convert to PCI hotplug API
commit fc1418cbccc453729296fbacaeaaa13e8b71a830
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 21:28:34 2007 -0400
[ISDN] HiSax: Convert w6692 driver to PCI hotplug API
[ed.: also, some additional EXPORT_SYMBOL and Makefile fixes]
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/Kconfig |2
drivers/isdn/hisax/Makefile |4 -
drivers/isdn/hisax/config.c | 23
drivers/isdn/hisax/isdnl1.c |2
drivers/isdn/hisax/lmgr.c |2
drivers/isdn/hisax/w6692.c | 116
6 files changed, 83 insertions(+), 66 deletions(-)
fc1418cbccc453729296fbacaeaaa13e8b71a830
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index b04503d..03e4ea5 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -325,7 +325,7 @@ config HISAX_HFC_PCI
.
config HISAX_W6692
- bool "Winbond W6692 based cards"
+ tristate "Winbond W6692 based cards"
depends on PCI
help
This enables HiSax support for Winbond W6692 based PCI ISDN cards.
diff --git a/drivers/isdn/hisax/Makefile b/drivers/isdn/hisax/Makefile
index e63e2af..1f02120 100644
--- a/drivers/isdn/hisax/Makefile
+++ b/drivers/isdn/hisax/Makefile
@@ -18,7 +18,8 @@ obj-$(CONFIG_HISAX_FRITZ_PCIPNP)+= hisax_isac.o
hisax_fcpcipnp.o
obj-$(CONFIG_HISAX_NETJET) += netjet_s.o libhisax.o
obj-$(CONFIG_HISAX_NETJET_U) += netjet_u.o libhisax.o
obj-$(CONFIG_HISAX_ENTERNOW_PCI) += enternow.o libhisax.o
-obj-$(CONFIG_HISAX_BKM_A4T)+= bkm_a4t_pci.o
+obj-$(CONFIG_HISAX_BKM_A4T)+= bkm_a4t_pci.o libhisax.o
+obj-$(CONFIG_HISAX_W6692) += w6692.o libhisax.o
bkm_a4t_pci-objs := bkm_a4t.o jade.o
enternow-objs := enternow_pci.o amd7930_fn.o
@@ -64,5 +65,4 @@ hisax-$(CONFIG_HISAX_ISURF) += isurf.o sar.o
hisax-$(CONFIG_HISAX_HSTSAPHIR)+= saphir.o hscx.o
hisax-$(CONFIG_HISAX_SCT_QUADRO) += bkm_a8.o hscx.o
hisax-$(CONFIG_HISAX_GAZEL)+= gazel.o hscx.o
-hisax-$(CONFIG_HISAX_W6692)+= w6692.o
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index 2ba96d0..163a636 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -257,13 +257,6 @@ const char *CardType[] = {
#define DEFAULT_CFG {15,0x180,0,0}
#endif
-#ifdef CONFIG_HISAX_W6692
-#undef DEFAULT_CARD
-#undef DEFAULT_CFG
-#define DEFAULT_CARD ISDN_CTYPE_W6692
-#define DEFAULT_CFG {0,0,0,0}
-#endif
-
#ifndef DEFAULT_CARD
#define DEFAULT_CARD 0
#define DEFAULT_CFG {0,0,0,0}
@@ -514,10 +507,6 @@ extern int setup_sct_quadro(struct IsdnCard *card);
extern int setup_gazel(struct IsdnCard *card);
#endif
-#if CARD_W6692
-extern int setup_w6692(struct IsdnCard *card);
-#endif
-
/*
* Find card with given driverId
*/
@@ -922,11 +911,6 @@ static int hisax_cs_setup_card(struct IsdnCard *card)
ret = setup_gazel(card);
break;
#endif
-#if CARD_W6692
- case ISDN_CTYPE_W6692:
- ret = setup_w6692(card);
- break;
-#endif
case ISDN_CTYPE_DYNAMIC:
ret = 2;
break;
@@ -936,6 +920,7 @@ static int hisax_cs_setup_card(struct IsdnCard *card)
case ISDN_CTYPE_NETJET_U:
case ISDN_CTYPE_ENTERNOW:
case ISDN_CTYPE_BKM_A4T:
+ case ISDN_CTYPE_W6692:
printk(KERN_WARNING "HiSax: Support for %s Card has moved "
"to separate PCI driver module\n",
CardType[card->typ]);
@@ -1397,7 +1382,6 @@ static int __init HiSax_init(void)
break;
case ISDN_CTYPE_ELSA_PCI:
case ISDN_CTYPE_TELESPCI:
- case ISDN_CTYPE_W6692:
break;
/* the following block are excluded from std HiSax init */
@@ -1405,6 +1389,7 @@ static int __init HiSax_init(void)
case ISDN_CTYPE_NETJET_U:
case ISDN_CTYPE_ENTERNOW:
case ISDN_CTYPE_BKM_A4T:
+ case ISDN_CTYPE_W6692:
break;
case ISDN_CTYPE_SCT_QUADRO:
@@ -1910,10 +1895,6 @@ static struct pci_device_id hisax_pci_tbl[]
__devinitdata = {
#if defined(CONFIG_HISAX_TELESPCI) || defined(CONFIG_HISAX_SCT_QUADRO)
{PCI_VENDOR_ID_ZORAN,PCI_DEVICE_ID_ZORAN_36120,
PCI_ANY_ID,PCI_ANY_ID},
#endif
-#ifdef CONFIG_HISAX_W6692
- {PCI_VENDOR_ID_DYNALINK, PCI_DEVICE_ID_DYNALINK_IS64PH,
PCI_ANY_ID,PCI_ANY_ID},
- {PCI_VENDOR_ID_WINBOND2, PCI_DEVICE_ID_WINBOND2_6692,
PCI_ANY_ID,PCI_ANY_ID},
-#endif
#ifdef CONFIG_HISAX_HFC_PCI
{PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_2BD0, PCI_ANY_ID,
PCI_ANY_ID},
{PCI_VENDOR_ID_CCD, PCI_DEVICE_ID_CCD_B000, PCI_ANY_ID,
PCI_ANY_ID},
diff --git
[PATCH 3/7] HiSax bkm_a4t: split setup into smaller functions
commit f3068817e23a05dbeeaa7dced579c7b64045b7ea
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 19:58:24 2007 -0400
[ISDN] HiSax bkm_a4t: split setup into two smaller functions
No behavior changes, just code movement. Prep for PCI hotplug API.
Well, CONFIG_PCI useless ifdef was removed.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/bkm_a4t.c | 108 +--
1 file changed, 63 insertions(+), 45 deletions(-)
f3068817e23a05dbeeaa7dced579c7b64045b7ea
diff --git a/drivers/isdn/hisax/bkm_a4t.c b/drivers/isdn/hisax/bkm_a4t.c
index 871310d..3d1bdc8 100644
--- a/drivers/isdn/hisax/bkm_a4t.c
+++ b/drivers/isdn/hisax/bkm_a4t.c
@@ -255,54 +255,38 @@ BKM_card_msg(struct IsdnCardState *cs, int mt, void *arg)
return (0);
}
-static struct pci_dev *dev_a4t __devinitdata = NULL;
+static int __devinit a4t_pci_probe(struct pci_dev *dev_a4t,
+ struct IsdnCardState *cs,
+ u_int *found,
+ u_int *pci_memaddr)
+{
+ u16 sub_sys;
+ u16 sub_vendor;
+
+ sub_vendor = dev_a4t->subsystem_vendor;
+ sub_sys = dev_a4t->subsystem_device;
+ if ((sub_sys == PCI_DEVICE_ID_BERKOM_A4T) && (sub_vendor ==
PCI_VENDOR_ID_BERKOM)) {
+ if (pci_enable_device(dev_a4t))
+ return (0); /* end loop & function */
+ *found = 1;
+ *pci_memaddr = pci_resource_start(dev_a4t, 0);
+ cs->irq = dev_a4t->irq;
+ return (1); /* end loop */
+ }
-int __devinit
-setup_bkm_a4t(struct IsdnCard *card)
+ return (-1);/* continue looping */
+}
+
+static int __devinit a4t_cs_init(struct IsdnCard *card,
+struct IsdnCardState *cs,
+u_int pci_memaddr)
{
- struct IsdnCardState *cs = card->cs;
- char tmp[64];
- u_int pci_memaddr = 0, found = 0;
I20_REGISTER_FILE *pI20_Regs;
-#ifdef CONFIG_PCI
-#endif
-
- strcpy(tmp, bkm_a4t_revision);
- printk(KERN_INFO "HiSax: T-Berkom driver Rev. %s\n", HiSax_getrev(tmp));
- if (cs->typ == ISDN_CTYPE_BKM_A4T) {
- cs->subtyp = BKM_A4T;
- } else
- return (0);
-#ifdef CONFIG_PCI
- while ((dev_a4t = pci_find_device(PCI_VENDOR_ID_ZORAN,
- PCI_DEVICE_ID_ZORAN_36120, dev_a4t))) {
- u16 sub_sys;
- u16 sub_vendor;
-
- sub_vendor = dev_a4t->subsystem_vendor;
- sub_sys = dev_a4t->subsystem_device;
- if ((sub_sys == PCI_DEVICE_ID_BERKOM_A4T) && (sub_vendor ==
PCI_VENDOR_ID_BERKOM)) {
- if (pci_enable_device(dev_a4t))
- return(0);
- found = 1;
- pci_memaddr = pci_resource_start(dev_a4t, 0);
- cs->irq = dev_a4t->irq;
- break;
- }
- }
- if (!found) {
- printk(KERN_WARNING "HiSax: %s: Card not found\n",
CardType[card->typ]);
- return (0);
- }
if (!cs->irq) { /* IRQ range check ?? */
printk(KERN_WARNING "HiSax: %s: No IRQ\n", CardType[card->typ]);
return (0);
}
- if (!pci_memaddr) {
- printk(KERN_WARNING "HiSax: %s: No Memory base address\n",
CardType[card->typ]);
- return (0);
- }
cs->hw.ax.base = (long) ioremap(pci_memaddr, 4096);
/* Check suspecious address */
pI20_Regs = (I20_REGISTER_FILE *) (cs->hw.ax.base);
@@ -317,11 +301,7 @@ setup_bkm_a4t(struct IsdnCard *card)
cs->hw.ax.jade_adr = cs->hw.ax.base + PO_OFFSET;
cs->hw.ax.isac_ale = GCS_1;
cs->hw.ax.jade_ale = GCS_3;
-#else
- printk(KERN_WARNING "HiSax: %s: NO_PCI_BIOS\n", CardType[card->typ]);
- printk(KERN_WARNING "HiSax: %s: unable to configure\n",
CardType[card->typ]);
- return (0);
-#endif /* CONFIG_PCI */
+
printk(KERN_INFO "HiSax: %s: Card configured at 0x%lX IRQ %d\n",
CardType[card->typ], cs->hw.ax.base, cs->irq);
@@ -339,5 +319,43 @@ setup_bkm_a4t(struct IsdnCard *card)
ISACVersion(cs, "Telekom A4T:");
/* Jade version */
JadeVersion(cs, "Telekom A4T:");
+
return (1);
}
+
+static struct pci_dev *dev_a4t __devinitdata = NULL;
+
+int __devinit
+setup_bkm_a4t(struct IsdnCard *card)
+{
+ struct IsdnCardState *cs = card->cs;
+ char tmp[64];
+ u_int pci_memaddr = 0, found = 0;
+ int ret;
+
+ strcpy(tmp, bkm_a4t_revision);
+ printk(KERN_INFO "HiSax: T-Berkom driver Rev. %s\n", HiSax_getrev(tmp));
+ if (cs->typ == ISDN_CTYPE_BKM_A4T) {
+ cs->subtyp = BKM_A4T;
+ } else
+ return (0);
+
[PATCH 1/7] HiSax enternow: split setup into smaller functions
commit a95641cdd42177eb0e9a772c591ca5383ee9c8ae
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 19:25:45 2007 -0400
[ISDN] HiSax enternow: split setup into 3 smaller functions
No behavior changes, just code movement. Prep for PCI hotplug API.
[also: removed CONFIG_PCI tests and CardType references]
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/enternow_pci.c | 165 --
1 file changed, 89 insertions(+), 76 deletions(-)
a95641cdd42177eb0e9a772c591ca5383ee9c8ae
diff --git a/drivers/isdn/hisax/enternow_pci.c
b/drivers/isdn/hisax/enternow_pci.c
index b45de9d..b73027f 100644
--- a/drivers/isdn/hisax/enternow_pci.c
+++ b/drivers/isdn/hisax/enternow_pci.c
@@ -300,98 +300,72 @@ enpci_interrupt(int intno, void *dev_id)
return IRQ_HANDLED;
}
-
-static struct pci_dev *dev_netjet __devinitdata = NULL;
-
-/* called by config.c */
-int __devinit
-setup_enternow_pci(struct IsdnCard *card)
+static int __devinit en_pci_probe(struct pci_dev *dev_netjet,
+ struct IsdnCardState *cs)
{
- int bytecnt;
- struct IsdnCardState *cs = card->cs;
- char tmp[64];
-
-#ifdef CONFIG_PCI
-#ifdef __BIG_ENDIAN
-#error "not running on big endian machines now"
-#endif
-strcpy(tmp, enternow_pci_rev);
- printk(KERN_INFO "HiSax: Formula-n Europe AG enter:now ISDN PCI driver
Rev. %s\n", HiSax_getrev(tmp));
- if (cs->typ != ISDN_CTYPE_ENTERNOW)
+ if (pci_enable_device(dev_netjet))
return(0);
- test_and_clear_bit(FLG_LOCK_ATOMIC, >HW_Flags);
-
- for ( ;; )
- {
- if ((dev_netjet = pci_find_device(PCI_VENDOR_ID_TIGERJET,
- PCI_DEVICE_ID_TIGERJET_300, dev_netjet))) {
- if (pci_enable_device(dev_netjet))
- return(0);
- cs->irq = dev_netjet->irq;
- if (!cs->irq) {
- printk(KERN_WARNING "enter:now PCI: No IRQ for
PCI card found\n");
- return(0);
- }
- cs->hw.njet.base = pci_resource_start(dev_netjet, 0);
- if (!cs->hw.njet.base) {
- printk(KERN_WARNING "enter:now PCI: No IO-Adr
for PCI card found\n");
- return(0);
- }
-/* checks Sub-Vendor ID because system crashes with
Traverse-Card */
- if ((dev_netjet->subsystem_vendor != 0x55) ||
- (dev_netjet->subsystem_device != 0x02)) {
- printk(KERN_WARNING "enter:now: You tried to
load this driver with an incompatible TigerJet-card\n");
-printk(KERN_WARNING "Use type=20 for Traverse
NetJet PCI Card.\n");
-return(0);
-}
- } else {
-printk(KERN_WARNING "enter:now PCI: No PCI card
found\n");
- return(0);
- }
-
- cs->hw.njet.auxa = cs->hw.njet.base + NETJET_AUXDATA;
- cs->hw.njet.isac = cs->hw.njet.base + 0xC0; // Fenster zum AMD
-
- /* Reset an */
- cs->hw.njet.ctrl_reg = 0x07; // geändert von 0xff
- outb(cs->hw.njet.ctrl_reg, cs->hw.njet.base + NETJET_CTRL);
- /* 20 ms Pause */
- mdelay(20);
+ cs->irq = dev_netjet->irq;
+ if (!cs->irq) {
+ printk(KERN_WARNING "enter:now PCI: No IRQ for PCI card
found\n");
+ return(0);
+ }
+ cs->hw.njet.base = pci_resource_start(dev_netjet, 0);
+ if (!cs->hw.njet.base) {
+ printk(KERN_WARNING "enter:now PCI: No IO-Adr for PCI card
found\n");
+ return(0);
+ }
+ /* checks Sub-Vendor ID because system crashes with Traverse-Card */
+ if ((dev_netjet->subsystem_vendor != 0x55) ||
+ (dev_netjet->subsystem_device != 0x02)) {
+ printk(KERN_WARNING "enter:now: You tried to load this driver
with an incompatible TigerJet-card\n");
+ printk(KERN_WARNING "Use type=20 for Traverse NetJet PCI
Card.\n");
+ return(0);
+ }
- cs->hw.njet.ctrl_reg = 0x30; /* Reset Off and status read
clear */
- outb(cs->hw.njet.ctrl_reg, cs->hw.njet.base + NETJET_CTRL);
- mdelay(10);
+ return(1);
+}
- cs->hw.njet.auxd = 0x00; // war 0xc0
- cs->hw.njet.dmactrl = 0;
+static void __devinit en_cs_init(struct IsdnCard *card,
+struct IsdnCardState *cs)
+{
+ cs->hw.njet.auxa = cs->hw.njet.base + NETJET_AUXDATA;
+ cs->hw.njet.isac = cs->hw.njet.base + 0xC0; // Fenster zum AMD
- outb(~TJ_AMD_IRQ,
[PATCH 2/7] HiSax enternow: convert to PCI hotplug API
commit 6c1225fd2735f698f59122209dd3c74d2e50ec28
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Sun Jul 15 19:41:21 2007 -0400
[ISDN] HiSax enternow_pci: convert to PCI hotplug API
Also, fix driver name in netjet_u.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/isdn/hisax/Kconfig|2
drivers/isdn/hisax/Makefile |3 -
drivers/isdn/hisax/config.c | 11
drivers/isdn/hisax/enternow_pci.c | 91 +++---
drivers/isdn/hisax/nj_u.c |2
5 files changed, 71 insertions(+), 38 deletions(-)
6c1225fd2735f698f59122209dd3c74d2e50ec28
diff --git a/drivers/isdn/hisax/Kconfig b/drivers/isdn/hisax/Kconfig
index 1da3cd6..7de6fda 100644
--- a/drivers/isdn/hisax/Kconfig
+++ b/drivers/isdn/hisax/Kconfig
@@ -341,7 +341,7 @@ config HISAX_HFC_SX
cards. This code is not finished yet.
config HISAX_ENTERNOW_PCI
- bool "Formula-n enter:now PCI card"
+ tristate "Formula-n enter:now PCI card"
depends on HISAX_NETJET && PCI && (BROKEN || !(SPARC || PPC || PARISC
|| M68K || (MIPS && !CPU_LITTLE_ENDIAN) || FRV))
help
This enables HiSax support for the Formula-n enter:now PCI
diff --git a/drivers/isdn/hisax/Makefile b/drivers/isdn/hisax/Makefile
index a37e211..db5580b 100644
--- a/drivers/isdn/hisax/Makefile
+++ b/drivers/isdn/hisax/Makefile
@@ -17,7 +17,9 @@ obj-$(CONFIG_HISAX_HFC4S8S) += hfc4s8s_l1.o
obj-$(CONFIG_HISAX_FRITZ_PCIPNP)+= hisax_isac.o hisax_fcpcipnp.o
obj-$(CONFIG_HISAX_NETJET) += netjet_s.o libhisax.o
obj-$(CONFIG_HISAX_NETJET_U) += netjet_u.o libhisax.o
+obj-$(CONFIG_HISAX_ENTERNOW_PCI) += enternow.o libhisax.o
+enternow-objs := enternow_pci.o amd7930_fn.o
netjet_s-objs := nj_s.o
netjet_u-objs := nj_u.o icc.o
libhisax-objs := netjet.o isac.o arcofi.o
@@ -62,5 +64,4 @@ hisax-$(CONFIG_HISAX_BKM_A4T) += bkm_a4t.o jade.o
hisax-$(CONFIG_HISAX_SCT_QUADRO) += bkm_a8.o hscx.o
hisax-$(CONFIG_HISAX_GAZEL)+= gazel.o hscx.o
hisax-$(CONFIG_HISAX_W6692)+= w6692.o
-hisax-$(CONFIG_HISAX_ENTERNOW_PCI) += enternow_pci.o amd7930_fn.o
diff --git a/drivers/isdn/hisax/config.c b/drivers/isdn/hisax/config.c
index 03c73e0..25320dd 100644
--- a/drivers/isdn/hisax/config.c
+++ b/drivers/isdn/hisax/config.c
@@ -529,10 +529,6 @@ extern int setup_gazel(struct IsdnCard *card);
extern int setup_w6692(struct IsdnCard *card);
#endif
-#if CARD_FN_ENTERNOW_PCI
-extern int setup_enternow_pci(struct IsdnCard *card);
-#endif
-
/*
* Find card with given driverId
*/
@@ -947,11 +943,6 @@ static int hisax_cs_setup_card(struct IsdnCard *card)
ret = setup_w6692(card);
break;
#endif
-#if CARD_FN_ENTERNOW_PCI
- case ISDN_CTYPE_ENTERNOW:
- ret = setup_enternow_pci(card);
- break;
-#endif
case ISDN_CTYPE_DYNAMIC:
ret = 2;
break;
@@ -959,6 +950,7 @@ static int hisax_cs_setup_card(struct IsdnCard *card)
/* list of ISDN_CTYPE_xxx support moved to a modular driver */
case ISDN_CTYPE_NETJET_S:
case ISDN_CTYPE_NETJET_U:
+ case ISDN_CTYPE_ENTERNOW:
printk(KERN_WARNING "HiSax: Support for %s Card has moved "
"to separate PCI driver module\n",
CardType[card->typ]);
@@ -1426,6 +1418,7 @@ static int __init HiSax_init(void)
/* the following block are excluded from std HiSax init */
case ISDN_CTYPE_NETJET_S:
case ISDN_CTYPE_NETJET_U:
+ case ISDN_CTYPE_ENTERNOW:
break;
case ISDN_CTYPE_BKM_A4T:
diff --git a/drivers/isdn/hisax/enternow_pci.c
b/drivers/isdn/hisax/enternow_pci.c
index b73027f..978b99a 100644
--- a/drivers/isdn/hisax/enternow_pci.c
+++ b/drivers/isdn/hisax/enternow_pci.c
@@ -61,6 +61,7 @@
#include "hisax.h"
+#include "hisax_proto.h"
#include "isac.h"
#include "isdnl1.h"
#include "amd7930_fn.h"
@@ -70,7 +71,7 @@
#include
#include "netjet.h"
-
+static int en_protocol;/* 0 == use DEFAULT_PROTO */
static const char *enternow_pci_rev = "$Revision: 1.1.4.5 $";
@@ -305,6 +306,8 @@ static int __devinit en_pci_probe(struct pci_dev
*dev_netjet,
{
if (pci_enable_device(dev_netjet))
return(0);
+
+ cs->hw.njet.dev = dev_netjet;
cs->irq = dev_netjet->irq;
if (!cs->irq) {
printk(KERN_WARNING "enter:now PCI: No IRQ for PCI card
found\n");
@@ -315,13 +318,6 @@ static int __devinit en_pci_probe(struct pci_dev
*dev_netjet,
printk(KERN_WARNING "enter:now PCI: No IO-Adr for PCI card
found\n");
return(0);
}
- /* checks Sub-Vendor ID because system crashes with Traverse-Card */
-
Re: Hibernation considerations
[EMAIL PROTECTED] writes: [snip] >> Isn't is possible to avoid this problem by mounting an ext3 filesystem >> as readonly ext2? Provided the filesystem isn't dirty it should be >> doable. (And provided the filesystem doesn't use any ext3 extensions >> that are incompatible with ext2.) > from the last discussion I saw on the kernel mailing list, no. the act of > mounting the ext3 filesystem as ext2 read-only will change it as the > unsupported > extentions get turned off (and I think the journal contents at least are lost > as > part of this) The fact of the matter is that it really doesn't matter whether mounting it read-only actually corrupts the data on disk or not. Regardless, it should not be done, because you are accessing a dirty filesystem that is still in use, and consequently there are no guarantees that either the metadata or the file contents are consistent. It isn't necessary for hibernation to be able to access mounted partitions anyway. -- Jeremy Maitin-Shepard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: kernel hang in ohci init
On Sunday 15 July 2007, Satyam Sharma wrote: > On 7/15/07, Timo Lindemann <[EMAIL PROTECTED]> wrote: > > It is just odd that up to (not including) the 2.6.21-series every kernel > > boots, and after that, they just freeze. On *your* system, note -- all my OHCI+PCI systems that have been upgraded to 2.6.22 are behaving just peachy-keen-swell. And that's true for most people, it seems... > > I am kinda stumped here. It gets that way sometimes. Thing is, pci-quirks.c runs early enough in the boot process -- before the OHCI driver can even run!! -- that you can probably rule out the USB stack as being the cause of this regression. Disable the USB host controllers in your config, and see what happens... > Hey, just try git-bisect already :-) > > In fact, you can first try by just reverting / un-applying that patch that > you initially had a suspicion on. Extremely unlikely to matter, since it wouldn't have been able to run that early. Plus, you were seeing problems even before that recent change to pci-quirks ... > Or, because you've already spent > some time tracking down the issue, you could simply go through the > git history of that file / subsystem in question Where the subsystem in question is early PCI/ACPI initialization, before the drivers start binding to PCI devices... it's always annoying when changes in that area cause USB to break, since the only involvement of USB is to display a "rude failure" symptom. It took a long time to get the IRQ setup glitches fixed! One thing you might do is enable all the ACPI debug messaging and disable the usb/host/pci-quirks.c stuff (just comment it all out), assuming you can boot without USB keyboard/mouse. Then compare the relevant diagnostics between "good" and "bad" kernels. It's likely something interesting will appear. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
Alan Stern wrote: > As for the VGA font, the effect is easy to see: Run setfont before > hibernating; when you resume the original font will be back. The > kernel simply does not bother to save the VGA font information across a > hibernate. This could probably be handled by a device suspend/resume call; but this problem is not specific to kexec. > > Ok, after applying the latest kexec patches, I was able to use the > > kexec'd kernel to suspend to ram and resume to the normal kernel, while > > working under a full-blown X session. It went without a hitch. All > > that is needed now are the dump/restore hibernation-image routines. > > That's exactly my point. While doing suspend-to-RAM from a kexec'd > kernel may be simple, saving the hibernation image will add > complications. >From a kexec'd hibernation kernel pov, both S3 and S4 look conceptually exactly the same. The only difference is, in S3 the memory is in memory and in S4 the memory is on storage. All device handling is exactly the same, so if there is a problem with device handling between the kexec'd hibernation kernel and the normal kernel, then that would have made itself visible. [EMAIL PROTECTED] wrote: > suspend-to-RAM should not involve kexec, the only reason for doing the > kexec to to get a seperate userspace to use for suspend-to-disk operations > instead of trying to partially freeze the sustem and keep useing it. Or you could do suspend-to-disk-and-RAM. But in the above case, it was meant to test kexec compatibility with device suspend/resume calls. Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22
> -Original Message- > From: Adrian Bunk [mailto:[EMAIL PROTECTED] > Sent: Sunday, July 15, 2007 4:46 PM > To: Li, Tong N > Cc: Giuseppe Bilotta; linux-kernel@vger.kernel.org > Subject: Re: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22 > > On Sun, Jul 15, 2007 at 10:47:51AM -0700, Li, Tong N wrote: > > > On Thursday 12 July 2007 00:17, Al Boldi wrote: > > > > > > > Peter Williams wrote: > > > >> > > > >> Probably the last one now that CFS is in the main line :-(. > > > > > > > > What do you mean? A pluggable scheduler framework is indispensible > > even > > > in > > > > the presence of CFS or SD. > > > > > > Indeed, and I hope it gets merged, giving people the chance to test > > out > > > different schedulers easily, without having to do patching, > > de-patching, > > > re-patching and blah blah blah. > > > > > > > Yes, such a framework would be invaluable, especially given that > > scheduling often has conflicting goals and different workloads have > > different requirements. No single solution fits all. > >... > > Having a framework for giving people the choice between different > solutions usually sounds good in theory, but in practice there's the > often underestimated high price of people using a different solution > instead of reporting a problem with one solution or people adding > features to only one of the solutions resulting in different solutions > having different features and bugs instead of one solution with all > features and bug fixes. > > So you should give a good technical explanation why it's not technically > possible or not desirable for one solution to work well for everyone. There are various metrics a scheduler may want to optimize for, such as throughput, response time, power consumption, fairness, and so on. Each of these may also be defined differently in different environments. Take fairness as an example. People have traditionally talked about it in terms of CPU time. Now it'd also make sense to talk about scheduling that enables fair usage of other types of resources, such as shared caches. Different metrics may require different scheduling policies. Plus, many metrics may in fact conflict, e.g., a scheduling policy optimized for throughput may not be power efficient. As a result, Linux, and all general-purpose OSes, strive to achieve a balance, but it's conceivable that different hardware platforms and different application workloads may want to have different scheduling policies to meet their own needs. Given that the scheduling policies can be diverse, the mechanisms to enforce them can also be different. The per-cpu runqueue model may be best for many scenarios, some scheduling policies (like many real-time ones) might want global knowledge about all tasks in the system and thus prefer a global task queue at the cost of being less scalable and cache-efficient. HPC systems may also want to gang-schedule. And, in terms of implementation, O(1) might be desirable for large-scale MP systems while O(log N) might be good enough for small systems. These are just examples that indicate the scheduler data structures, algorithms, and implementation can have a variety of possibilities in different usage models. A single scheduler that is easily extensible for incorporating different policies would be ideal, but IMO this is not yet the case and may not even be possible. Therefore, I think having a framework that enables multiple schedulers to co-exist would be invaluable and PlugSched seems to be one good step towards this. tong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[rfc][patch 2/2] x86_64: FIFO ticket spinlocks
Introduce ticket lock spinlocks for x86-64 which are FIFO. The implementation
is described in the comments. The straight-line lock/unlock instruction
sequence is slightly slower than the dec based locks on modern x86 CPUs,
however the difference is quite small on Core2 and Opteron when working out of
cache, and becomes almost insignificant even on P4 when the lock misses cache.
trylock is more significantly slower, but they are relatively rare.
The memory ordering of the lock does conform to Intel's standards, and the
implementation has been reviewed by an Intel engineer.
XXX: numbers here
The algorithm also tells us how many CPUs are contending the lock, so
lockbreak becomes trivial and we no longer waste 4 bytes per spinlock for it.
---
Index: linux-2.6/include/asm-x86_64/spinlock.h
===
--- linux-2.6.orig/include/asm-x86_64/spinlock.h
+++ linux-2.6/include/asm-x86_64/spinlock.h
@@ -19,67 +19,81 @@
static inline int __raw_spin_is_locked(raw_spinlock_t *lock)
{
- return *(volatile signed int *)(&(lock)->slock) <= 0;
+ int tmp = *(volatile signed int *)(&(lock)->slock);
+
+ return (((tmp >> 8) & 0xff) != (tmp & 0xff));
}
-static inline void __raw_spin_lock(raw_spinlock_t *lock)
+static inline int __raw_spin_is_contended(raw_spinlock_t *lock)
{
- asm volatile(
- "\n1:\t"
- LOCK_PREFIX " ; decl %0\n\t"
- "jns 2f\n"
- "3:\n"
- "rep;nop\n\t"
- "cmpl $0,%0\n\t"
- "jle 3b\n\t"
- "jmp 1b\n"
- "2:\t" : "=m" (lock->slock) : : "memory");
+ int tmp = *(volatile signed int *)(&(lock)->slock);
+
+ return (((tmp >> 8) & 0xff) - (tmp & 0xff)) > 1;
}
-/*
- * Same as __raw_spin_lock, but reenable interrupts during spinning.
- */
-#ifndef CONFIG_PROVE_LOCKING
-static inline void __raw_spin_lock_flags(raw_spinlock_t *lock, unsigned long
flags)
+static inline void __raw_spin_lock(raw_spinlock_t *lock)
{
- asm volatile(
- "\n1:\t"
- LOCK_PREFIX " ; decl %0\n\t"
- "jns 5f\n"
- "testl $0x200, %1\n\t" /* interrupts were disabled? */
- "jz 4f\n\t"
- "sti\n"
- "3:\t"
- "rep;nop\n\t"
- "cmpl $0, %0\n\t"
- "jle 3b\n\t"
- "cli\n\t"
+ short inc = 0x0100;
+
+ /*
+* Ticket locks are conceptually two bytes, one indicating the current
+* head of the queue, and the other indicating the current tail. The
+* lock is acquired by atomically noting the tail and incrementing it
+* by one (thus adding ourself to the queue and noting our position),
+* then waiting until the head becomes equal to the the initial value
+* of the tail.
+*
+* This uses a 16-bit xadd to increment the tail and also load the
+* position of the head, which takes care of memory ordering issues
+* and should be optimal for the uncontended case. Note the tail must
+* be in the high byte, otherwise the 16-bit wide increment of the low
+* byte would carry up and contaminate the high byte.
+*/
+
+ __asm__ __volatile__ (
+ LOCK_PREFIX "xaddw %w0, %1\n"
+ "1:\t"
+ "cmpb %h0, %b0\n\t"
+ "je 2f\n\t"
+ "rep ; nop\n\t"
+ "movb %1, %b0\n\t"
+ "lfence\n\t"
"jmp 1b\n"
- "4:\t"
- "rep;nop\n\t"
- "cmpl $0, %0\n\t"
- "jg 1b\n\t"
- "jmp 4b\n"
- "5:\n\t"
- : "+m" (lock->slock) : "r" ((unsigned)flags) : "memory");
+ "2:"
+ :"+Q" (inc), "+m" (lock->slock)
+ :
+ :"memory", "cc");
}
-#endif
+
+#define __raw_spin_lock_flags(lock, flags) __raw_spin_lock(lock)
static inline int __raw_spin_trylock(raw_spinlock_t *lock)
{
- int oldval;
+ short tmp;
+short oldval;
asm volatile(
- "xchgl %0,%1"
- :"=q" (oldval), "=m" (lock->slock)
- :"0" (0) : "memory");
+"movw %2,%w0\n\t"
+"cmpb %h0, %b0\n\t"
+"jne 1f\n\t"
+"movw %w0,%w1\n\t"
+"incb %h1\n\t"
+LOCK_PREFIX "cmpxchgw %w1,%2\n\t"
+"1:"
+:"=a" (oldval), "=Q" (tmp), "+m" (lock->slock)
+:
+ : "memory", "cc");
- return oldval > 0;
+ return ((oldval & 0xff) == ((oldval >> 8) & 0xff));
}
static inline void __raw_spin_unlock(raw_spinlock_t *lock)
{
- asm volatile("movl $1,%0" :"=m" (lock->slock) :: "memory");
+ __asm__ __volatile__(
+ "incb %0"
+ :"+m" (lock->slock)
+ :
+
[rfc][patch 1/2] spinlock: lockbreak cleanups
Hi,
These patches are not exactly complete yet (haven't tested many config
combinations or converted other architectures), but I want to post it
now to get consensus on whether and how to clean up the lockbreak stuff
in particular.
It gets in the way because ticket spinlocks shouldn't be just repeating
the low-level trylock to lock, because that never gives the locker a
ticket, so the FIFO order is ruined.
So RFC.
---
The break_lock data structure and code for spinlocks is quite nasty.
Not only does it double the size of a spinlock but it changes locking to
a potentially less optimal trylock.
Put all of that under CONFIG_GENERIC_LOCKBREAK, and introduce a
__raw_spin_is_contended that uses the lock data itself to determine whether
there are waiters on the lock, to be used if CONFIG_GENERIC_LOCKBREAK is
not set.
Rename need_lockbreak to spin_needbreak, make it use spin_is_contended to
decouple it from the spinlock implementation, and make it typesafe (rwlocks
do not have any need_lockbreak sites -- why do they even get bloated up
with that break_lock then?).
After this, we can no longer spin on any locks with preempt enabled
(unless that is done in arch code), but that (and spinning with
interrupts enabled) is hackish anyway: if the lock happens to be
called under a preempt or interrupt disabled section, then it is just
going to have the same problems. The real fix is to keep critical
sections short, and introduce fairer locks if there are starvation
issues.
---
Index: linux-2.6/include/linux/sched.h
===
--- linux-2.6.orig/include/linux/sched.h
+++ linux-2.6/include/linux/sched.h
@@ -1598,26 +1598,16 @@ extern int cond_resched_softirq(void);
/*
* Does a critical section need to be broken due to another
- * task waiting?:
+ * task waiting?: (technically does not depend on CONFIG_PREEMPT,
+ * but a general need for low latency)
*/
-#if defined(CONFIG_PREEMPT) && defined(CONFIG_SMP)
-# define need_lockbreak(lock) ((lock)->break_lock)
+#ifdef CONFIG_PREEMPT
+# define spin_needbreak(lock) spin_is_contended(lock)
#else
-# define need_lockbreak(lock) 0
+# define spin_needbreak(lock) 0
#endif
/*
- * Does a critical section need to be broken due to another
- * task waiting or preemption being signalled:
- */
-static inline int lock_need_resched(spinlock_t *lock)
-{
- if (need_lockbreak(lock) || need_resched())
- return 1;
- return 0;
-}
-
-/*
* Reevaluate whether the task has signals pending delivery.
* Wake the task if so.
* This is required every time the blocked sigset_t changes.
Index: linux-2.6/include/linux/spinlock.h
===
--- linux-2.6.orig/include/linux/spinlock.h
+++ linux-2.6/include/linux/spinlock.h
@@ -120,6 +120,12 @@ do {
\
#define spin_is_locked(lock) __raw_spin_is_locked(&(lock)->raw_lock)
+#ifdef CONFIG_GENERIC_LOCKBREAK
+#define spin_is_contended(lock) ((lock)->break_lock)
+#else
+#define spin_is_contended(lock)
__raw_spin_is_contended(&(lock)->raw_lock)
+#endif
+
/**
* spin_unlock_wait - wait until the spinlock gets unlocked
* @lock: the spinlock in question.
Index: linux-2.6/fs/jbd/checkpoint.c
===
--- linux-2.6.orig/fs/jbd/checkpoint.c
+++ linux-2.6/fs/jbd/checkpoint.c
@@ -347,7 +347,8 @@ restart:
break;
}
retry = __process_buffer(journal, jh, bhs,_count);
- if (!retry && lock_need_resched(>j_list_lock)){
+ if (!retry && (need_resched() ||
+ spin_needbreak(>j_list_lock))) {
spin_unlock(>j_list_lock);
retry = 1;
break;
Index: linux-2.6/fs/jbd/commit.c
===
--- linux-2.6.orig/fs/jbd/commit.c
+++ linux-2.6/fs/jbd/commit.c
@@ -265,7 +265,7 @@ write_out_data:
put_bh(bh);
}
- if (lock_need_resched(>j_list_lock)) {
+ if (need_resched() || spin_needbreak(>j_list_lock)) {
spin_unlock(>j_list_lock);
goto write_out_data;
}
Index: linux-2.6/fs/jbd2/checkpoint.c
===
--- linux-2.6.orig/fs/jbd2/checkpoint.c
+++ linux-2.6/fs/jbd2/checkpoint.c
@@ -347,7 +347,8 @@ restart:
break;
}
retry = __process_buffer(journal, jh, bhs,_count);
- if (!retry && lock_need_resched(>j_list_lock)){
+ if (!retry && (need_resched() ||
+
[git pull] drm patches for 2.6.23-rc1 - FIXED
Hi Linus, (apologies for the first borked tree, I cross compiled this for ppc64, you can blame Telstra - no ADSL or phone at home) Please pull the 'drm-patches' branch from the drm git tree. ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches It contains a removal of a lot of typedefs from the core drm and their use in drivers. Drivers will have their own typedefs cleaned later. It also fixes the 32-bit compat ioctl code It also contains an updated r300 register file, and radeon vblank routing support along with a list macro cleanup. drivers/char/drm/ati_pcigart.c|8 +- drivers/char/drm/drm.h| 329 ++- drivers/char/drm/drmP.h | 349 ++-- drivers/char/drm/drm_agpsupport.c | 116 ++-- drivers/char/drm/drm_auth.c | 40 +- drivers/char/drm/drm_bufs.c | 209 drivers/char/drm/drm_context.c| 97 ++-- drivers/char/drm/drm_dma.c| 12 +- drivers/char/drm/drm_drawable.c | 34 +- drivers/char/drm/drm_drv.c| 76 ++-- drivers/char/drm/drm_fops.c | 68 +-- drivers/char/drm/drm_hashtab.c| 34 +- drivers/char/drm/drm_hashtab.h| 24 +- drivers/char/drm/drm_ioc32.c | 82 ++-- drivers/char/drm/drm_ioctl.c | 68 ++- drivers/char/drm/drm_irq.c| 58 +- drivers/char/drm/drm_lock.c | 28 +- drivers/char/drm/drm_memory.c |8 +- drivers/char/drm/drm_mm.c | 66 +- drivers/char/drm/drm_os_linux.h | 22 +- drivers/char/drm/drm_pci.c|6 +- drivers/char/drm/drm_proc.c | 50 +- drivers/char/drm/drm_sarea.h | 26 +- drivers/char/drm/drm_scatter.c| 22 +- drivers/char/drm/drm_sman.c | 93 ++-- drivers/char/drm/drm_sman.h | 50 +- drivers/char/drm/drm_stub.c | 30 +- drivers/char/drm/drm_sysfs.c |4 +- drivers/char/drm/drm_vm.c | 106 ++-- drivers/char/drm/i810_dma.c | 164 +++--- drivers/char/drm/i810_drm.h |2 +- drivers/char/drm/i810_drv.h | 18 +- drivers/char/drm/i830_dma.c | 157 +++--- drivers/char/drm/i830_drm.h |2 +- drivers/char/drm/i830_drv.h | 24 +- drivers/char/drm/i830_irq.c | 20 +- drivers/char/drm/i915_dma.c | 44 +- drivers/char/drm/i915_drm.h |8 +- drivers/char/drm/i915_drv.h | 22 +- drivers/char/drm/i915_irq.c | 28 +- drivers/char/drm/i915_mem.c |6 +- drivers/char/drm/mga_dma.c| 79 ++-- drivers/char/drm/mga_drm.h|6 +- drivers/char/drm/mga_drv.c|4 +- drivers/char/drm/mga_drv.h| 22 +- drivers/char/drm/mga_irq.c| 12 +- drivers/char/drm/mga_state.c | 36 +- drivers/char/drm/r128_cce.c | 41 +- drivers/char/drm/r128_drm.h |4 +- drivers/char/drm/r128_drv.h | 20 +- drivers/char/drm/r128_irq.c | 10 +- drivers/char/drm/r128_state.c | 60 +- drivers/char/drm/r300_cmdbuf.c| 53 +- drivers/char/drm/r300_reg.h | 1163 + drivers/char/drm/radeon_cp.c | 54 +- drivers/char/drm/radeon_drm.h | 12 +- drivers/char/drm/radeon_drv.c |3 +- drivers/char/drm/radeon_drv.h | 45 +- drivers/char/drm/radeon_irq.c | 118 - drivers/char/drm/radeon_state.c | 108 ++-- drivers/char/drm/savage_bci.c | 44 +- drivers/char/drm/savage_drm.h |4 +- drivers/char/drm/savage_drv.h | 20 +- drivers/char/drm/savage_state.c | 28 +- drivers/char/drm/sis_drv.c|4 +- drivers/char/drm/sis_drv.h|9 +- drivers/char/drm/sis_mm.c | 16 +- drivers/char/drm/via_dma.c| 10 +- drivers/char/drm/via_dmablit.c| 20 +- drivers/char/drm/via_dmablit.h|2 +- drivers/char/drm/via_drm.h|4 +- drivers/char/drm/via_drv.h| 32 +- drivers/char/drm/via_irq.c| 12 +- drivers/char/drm/via_map.c| 10 +- drivers/char/drm/via_mm.c |6 +- drivers/char/drm/via_verifier.c | 12 +- drivers/char/drm/via_verifier.h |6 +- 77 files changed, 2485 insertions(+), 2214 deletions(-) commit ff4135aeb1f9a0201f8e22400ebc1d570df9016e Author: Dave Airlie <[EMAIL PROTECTED]> Date: Mon Jul 16 13:53:57 2007 +1000 drm: remove core typedefs from the ioc32 wrappers Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit bd63cb52c05bbb154f539369cae4fb9c9b6277da Author: Dave Airlie <[EMAIL PROTECTED]> Date: Thu Jul 12 10:35:02 2007 +1000 drm: remove sarea typedefs Leave the userspace typedefs in place Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit e0be428e6645f2891fab6be92d1b0e9aad972e7d Author: Dave Airlie <[EMAIL PROTECTED]> Date: Thu Jul 12 10:26:44 2007 +1000 drm: detypedef the hashtab and more of sman Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit 9698b4dba42eb758ad98012c21e5fbdb372fe2d9 Author: Dave Airlie <[EMAIL PROTECTED]>
Re: [PATCH] Add KERN_* prefix to printks in bug.h
On Sun, Jul 15, 2007 at 09:36:59PM -0300, Diego Woitasen wrote:
> ---
> include/asm-generic/bug.h | 25 +
> 1 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
> index 7f30cce..6e49266 100644
> --- a/include/asm-generic/bug.h
> +++ b/include/asm-generic/bug.h
> @@ -8,22 +8,23 @@
> #ifdef CONFIG_GENERIC_BUG
> #ifndef __ASSEMBLY__
> struct bug_entry {
> - unsigned long bug_addr;
> + unsigned long bug_addr;
Never include unrelated changes.
> #ifdef CONFIG_DEBUG_BUGVERBOSE
> - const char *file;
> - unsigned short line;
> + const char *file;
> + unsigned short line;
> #endif
> - unsigned short flags;
> + unsigned short flags;
> };
> -#endif /* __ASSEMBLY__ */
> +#endif /* __ASSEMBLY__ */
>
> #define BUGFLAG_WARNING (1<<0)
> -#endif /* CONFIG_GENERIC_BUG */
> +#endif /* CONFIG_GENERIC_BUG */
>
> #ifndef HAVE_ARCH_BUG
> -#define BUG() do { \
> - printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__,
> __FUNCTION__); \
> - panic("BUG!"); \
> +#define BUG() do { \
> + printk(KERN_EMERG "BUG: failure at %s:%d/%s()!\n", \
> + __FILE__, __LINE__, __FUNCTION__); \
> + panic("BUG!"); \
> } while (0)
> #endif
>
> @@ -35,15 +36,15 @@ struct bug_entry {
> #define WARN_ON(condition) ({
> \
> typeof(condition) __ret_warn_on = (condition); \
> if (unlikely(__ret_warn_on)) { \
> - printk("WARNING: at %s:%d %s()\n", __FILE__,\
> - __LINE__, __FUNCTION__);\
> + printk(KERN_WARNING "WARNING: at %s:%d %s()\n", \
> + __FILE__, __LINE__, __FUNCTION__); \
> dump_stack(); \
> } \
> unlikely(__ret_warn_on);\
> })
> #endif
>
> -#else /* !CONFIG_BUG */
> +#else/* !CONFIG_BUG */
> #ifndef HAVE_ARCH_BUG
> #define BUG()
> #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BUG: unable to handle kernel NULL pointer dereference - nfs v3
Hi, I'm not sure is the good place to poste that, and if not - please excuse me. I was running nfs server v2 since a year on one server, there is few days, i have update my kernel to 2.6.21.3 with support of nfsv3 server. Somes times per days i have somes crash as below, needing i reboot the server to nfs re-become up. BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 printing eip: c01e7279 *pde = 09ecc001 Oops: [#1] SMP CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010246 (2.6.21.3-sdf88-core #9) EIP is at encode_fsid+0x67/0x89 eax: e5bde8c0 ebx: f7593404 ecx: edx: 0006 esi: dc569048 edi: f75934ec ebp: f7593404 esp: f75f1f18 ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process nfsd (pid: 3386, ti=f75f task=f7b295b0 task.ti=f75f) Stack: dc569048 c01e7381 f5bd0df8 c01e5bde f6c95000 c01e7fdf dc56901c c0519584 c01e7ffc f75934ec f6c95000 c01dd38a f77d68c0 d0ab4200 c043d99e dc569014 f6c95000 f6c950e0 f7593538 c0519584 c0439f32 Call Trace: [] encode_fattr3+0xe6/0x131 [] nfsd3_proc_getattr+0xaf/0xb9 [] nfs3svc_encode_attrstat+0x0/0x3b [] nfs3svc_encode_attrstat+0x1d/0x3b [] nfsd_dispatch+0x13e/0x190 [] svcauth_unix_set_client+0x152/0x15e [] svc_process+0x38d/0x636 [] nfsd+0x171/0x26e [] nfsd+0x0/0x26e [] kernel_thread_helper+0x7/0x10 === Code: e2 08 09 d1 09 c1 eb 10 8b 83 88 00 00 00 8b 40 30 89 c3 89 c1 c1 fb 1f 89 d8 0f c8 89 06 89 c8 eb 1e Best regards, -- David - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Determine version of kernel that produced vmcore
On Fri, Jul 13, 2007 at 03:15:50PM +0200, Bernhard Walle wrote: > * Ken'ichi Ohmichi <[EMAIL PROTECTED]> [2007-07-13 13:05]: > > > > BTW, I'd like to remove PAGESIZE from a mkdfinfo file. > > While 2nd-kernel is running, new makedumpfile comes to consider > > 2nd-kernel PAGESIZE as 1st-kernel PAGESIZE without getting PAGESIZE > > from a mkdfinfo file. > > I don't think that's a good idea. IMO the kernel should be modified to > export the page size in a variable for that purpose. That would solve > all problems and dependencies, doesn't it? > Agreed. We need to export PAGESIZE from kernel instead of assuming that second kernel as got same page size as first kernel. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] eCryptfs: ecryptfs_setattr() bugfix
There is another bug recently introduced into the ecryptfs_setattr()
function in 2.6.22. eCryptfs will attempt to treat special files like
regular eCryptfs files on chmod, chown, and so forth. This leads to a
NULL pointer dereference. This patch validates that the file is a
regular file before proceeding with operations related to the inode's
crypt_stat.
Thanks to Ryusuke Konishi for finding this bug and suggesting the fix.
Signed-off-by: Michael Halcrow <[EMAIL PROTECTED]>
---
fs/ecryptfs/inode.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c
index 83e94fe..9c6877c 100644
--- a/fs/ecryptfs/inode.c
+++ b/fs/ecryptfs/inode.c
@@ -902,8 +902,9 @@ static int ecryptfs_setattr(struct dentry *dentry, struct
iattr *ia)
mutex_lock(_stat->cs_mutex);
if (S_ISDIR(dentry->d_inode->i_mode))
crypt_stat->flags &= ~(ECRYPTFS_ENCRYPTED);
- else if (!(crypt_stat->flags & ECRYPTFS_POLICY_APPLIED)
-|| !(crypt_stat->flags & ECRYPTFS_KEY_VALID)) {
+ else if (S_ISREG(dentry->d_inode->i_mode)
+&& (!(crypt_stat->flags & ECRYPTFS_POLICY_APPLIED)
+|| !(crypt_stat->flags & ECRYPTFS_KEY_VALID))) {
struct vfsmount *lower_mnt;
struct file *lower_file = NULL;
struct ecryptfs_mount_crypt_stat *mount_crypt_stat;
--
1.5.2.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.22.1] libata: Adjust libata to ignore errors after spinup
From: Ryan Power <[EMAIL PROTECTED]>
Adjust libata to ignore errors after spinup
This patch is to ignore errors from the spinup attempt if the drive is
in the "standby id" state.
Signed-off-by: Ryan Power <[EMAIL PROTECTED]>
---
Index: drivers.new/ata/libata-core.c
--- drivers/ata/libata-core.c 2007-07-10 12:56:30.0 -0600
+++ drivers.new/ata/libata-core.c 2007-07-15 01:58:49.0 -0600
@@ -1750,7 +1750,7 @@ int ata_dev_read_id(struct ata_device *d
tf.protocol = ATA_PROT_NODATA;
tf.flags |= ATA_TFLAG_ISADDR | ATA_TFLAG_DEVICE;
err_mask = ata_exec_internal(dev, , NULL, DMA_NONE,
NULL, 0);
- if (err_mask) {
+ if (err_mask && id[2] != 0x738c) {
rc = -EIO;
reason = "SPINUP failed";
goto err_out;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux.conf.au - Friday 20 July - Call for Presentations
Are you planning on submitting a talk or tutorial for linux.conf.au 2008? http://linux.conf.au/presentations/announcement Get your submissions in by Friday 20th July. And for those of you concerned about the video option - please don't worry. It's entirely optional. We are aware that many people don't have the means or expertise to make a video and get it online - but for those who do, for those who want to, go for it! Cheers, - P. -- peter lieverdinklinux.conf.au secretary MEL8OURNE2008 www.mel8ourne.org must.be.there 9662 1CB5 8E54 450D 2E12 9D7E 580E 2519 969F 3F57 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Chinese Language Maintainer
Tsugikazu Shibata wrote: > > Yes, In Japan, situation is mostly the same. > We are trying to increase number of Linux community developer with > Linux Foundation Japan or CELF people in Japan. > In our discussion, the problem is not only Language. > > In case of some developer, once he step forward (he try to send patch > or comment on LKML), he got some comment and he can work with > community even if it's slow (because of he was non-native). > So, I thought if some key document are available in Japanese like > HOWTO, that will help such early stage of developers. > I think you're absolutely right about that. The stuff that will help most of have translated is (kernel)newbie type documentation, the stuff one wants when being introduced to the community. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Chinese Language Maintainer
On Sun, 15 Jul 2007 22:42:07 +0800, leo wrote: > On 7/14/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > On Friday 13 July 2007 8:43:03 am Li Yang wrote: > > > On Thu, 2007-07-12 at 12:05 -0400, Rob Landley wrote: > > > > +A language maintainer accepts patches to the Linux kernel, written in > > > > C, > > > > from +authors who do not also speak English. The language maintainer > > > > translates the +description of each patch into English, forwards the > > > > patches to linux-kernel +and to the appropriate maintainers for > > > > inclusion > > > > in the Linux kernel, and +translates questions and replies about such > > > > patches as part of the +patch review process. > > > > > > In addiction to this responsibility, I would like to add two more which, > > > in my opinion, are more important. And these are what I'm trying to > > > do. :) > > > First, promoting contribution to Linux kernel in local language. > > > Second, coordinate the translation effort of key kernel documents. > > > > Cool. It's good to do that, but not the problem I'm worried about solving. > > > > I was trying to describe the minimum requirements for being a language > > maintainer, I.E. what non-english users need in order to be able to merge > > their patches. Because without someone to contribute patches to (I.E a > > language maintainer), documentation in non-english languages promotes the > > creation of patches that can't be merged. That's the problem I'm trying to > > solve. > > > > To me, finding language maintainers is the flip side of the coin of > > translating documentation. > > I think you worried too much about this problem. :) Let me explain > the situation here in China more clearly. Actually, English is > mandatory in most schools and universities. Only very few people > learn other language as a second language. Therefore software > developers who are almost educated should have the basic English > skill. However, that doesn't mean that they can read English or > communicate with native English speaker very easily. Consider your > second language learn in school for analogy. Read in English will be > much slower and more likely to cause misunderstanding. This will > reduce the likelihood greatly of English documentation being read. If > we are promoting contribution to the Linux community, we should > maximum the possibility that these key documents being read. > Translation will serve this purpose very well. > > So the possibility is very little that a translator is needed between > the Linux maintainer and a Chinese developer. Although sometimes help > is needed when there is misunderstanding. > > After a brief talk with the Japanese translator, I think the case is > similar for Japanese too. Yes, In Japan, situation is mostly the same. We are trying to increase number of Linux community developer with Linux Foundation Japan or CELF people in Japan. In our discussion, the problem is not only Language. In case of some developer, once he step forward (he try to send patch or comment on LKML), he got some comment and he can work with community even if it's slow (because of he was non-native). So, I thought if some key document are available in Japanese like HOWTO, that will help such early stage of developers. > Therefore, in my opinion, language maintainer should be more a helper > and promoter rather than a gatekeeper. I will give a proposed process > later about how this helper mechanism works. I will be able to help this as a stand point of Japanese situation. > - Leo > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] minimal fixes for drivers/usb/gadget/m66592-udc.c
On Sunday 15 July 2007, Al Viro wrote: > On Sun, Jul 15, 2007 at 04:18:10PM -0700, David Brownell wrote: > > Re the leaks, in probe() request_irq() isn't cleaned up ... but it > > looked to me like the rest of the allocations did get cleaned up > > afer probe() errors. But remove() does indeed leak the memory you > > highlighted. > > Why not make ep0_buf a 16bit field in that struct? Ask the driver author. :) That should work, given proper byteswapping. It's only used to transmit certain results. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/mmc/core/: make 4 functions static
On Sun, Jul 15, 2007 at 06:52:34PM +0200, Pierre Ossman wrote: > On Fri, 13 Jul 2007 01:56:02 +0200 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > This patch makes the following needlessly global functions static: > > - sd_ops.c: mmc_wait_for_app_cmd() > > - core.c: mmc_start_request() > > I am a bit torn about these two. Even though we don't cater to > out-of-tree stuff, having these as exported symbols shows that they are > part of the API. Removing them might risk people going about doing > something silly because they don't know the functionality exists, and > we might not spot it at patch review time. If mmc_start_request() is considered part of an API people should use, why isn't there a prototype in a header file? > Rgds cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/6] Driver Tracing Interface (DTI) code
On Fri, 29 Jun 2007 22:23:53 -0500 Tom Zanussi wrote:
> The Driver Tracing Interface (DTI) code.
>
> Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>
> ---
> drivers/base/Kconfig | 11
> drivers/base/Makefile |1
> drivers/base/dti.c | 836
> +
> drivers/base/dti_merged_view.c | 332
> include/linux/dti.h| 293 ++
> 5 files changed, 1473 insertions(+)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 5d6312e..fbc9c0e 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -49,6 +49,17 @@ config DEBUG_DEVRES
>
> If you are unsure about this, Say N here.
>
> +config DTI
> + bool "Driver Tracing Interface (DTI)"
> + select GTSC
> + help
> + Provides functions to write variable length trace records
> + into a wraparound memory trace buffer. One purpose of
> + this is to inspect the debug traces after a system crash in order to
> + analyze the reason for the failure. The traces are accessable from
> + system dumps via dump analysis tools like crash or lcrash. In live
> + systems the traces can be read via a debugfs interface.
> +
Indent help text by 2 spaces, i.e., tab + 2 spaces.
> config SYS_HYPERVISOR
> bool
> default n
> diff --git a/drivers/base/dti.c b/drivers/base/dti.c
> new file mode 100644
> index 000..2feec11
> --- /dev/null
> +++ b/drivers/base/dti.c
> @@ -0,0 +1,836 @@
> +
> +extern int dti_create_merged_views(struct dti_info *dti);
> +extern void dti_remove_merged_views(struct dti_info *dti);
externs need to be in some header file.
> +struct file_operations level_fops;
> +
> +/**
> + * dti_register_level: create trace dir and level ctrl file
s/: / - / to be consistent with rest (or most) of kernel. I.e.,
kernel-doc function format is
* @func - short description
(throughout source file(s))
OK, the : is optional, but the - is needed.
> + *
> + * Internal - exported for setup macros.
> + */
> +struct dti_info *dti_register_level(const char *name, int level,
> + struct dti_handle *handle)
> +{
> + return __dti_register_level(name, level, sub_size(handle->size),
> + nr_sub(handle->size), handle);
> +}
> +EXPORT_SYMBOL_GPL(dti_register_level);
> +
> diff --git a/drivers/base/dti_merged_view.c b/drivers/base/dti_merged_view.c
> new file mode 100644
> index 000..b3fee0f
> --- /dev/null
> +++ b/drivers/base/dti_merged_view.c
> @@ -0,0 +1,332 @@
> +
> +struct dti_merged_view_info {
> + void *next_event; /* NULL if at end of buffer */
> + struct timeval last_read;
> + int cpu;
> + unsigned long long bytes_left;
> + void *buf;
> +loff_t pos;
use tab above instead of spaces.
> +};
> +
> +struct dti_merged_view {
> + void *current_header; /* header currently being read */
> + ssize_t header_bytes_left;
> + char header[80];
> + void *current_event; /* record currently being read */
> + ssize_t event_bytes_left;
> + struct rchan *chan;
> + int show_timestamps;
> + struct dti_merged_view_info info[NR_CPUS]; /* per-cpu buffer info */
> +} __attribute__ ((packed));
> +
> +struct file_operations dti_merged_view_fops;
> +struct file_operations dti_merged_ts_view_fops;
> +
> +/**
> + * dti_create_merged_views:
> + * Creates merged view files in the trace's parent.
Short description needs to be on same line as function name.
> + *
> + * @trace: trace handle to create view of
> + *
> + * returns 0 on sucess.
> + */
> +int dti_create_merged_views(struct dti_info *dti)
> +{
> + struct dentry *parent = dti->trace->dir;
> +
> + dti->merged_view = debugfs_create_file("merged", 0, parent, dti,
> +_merged_view_fops);
> +
> + if (dti->merged_view == NULL ||
> + dti->merged_view == (struct dentry *)-ENODEV)
> + goto cleanup;
> +
> + dti->merged_ts_view = debugfs_create_file("merged-ts",
> + 0, parent, dti,
> + _merged_ts_view_fops);
> +
> + if (dti->merged_ts_view == NULL ||
> + dti->merged_ts_view == (struct dentry *)-ENODEV)
> + goto cleanup;
> +
> + return 0;
> +cleanup:
> + dti_remove_merged_views(dti);
> +
> + return -ENOMEM;
> +}
> +
> +static int dti_merged_view_close(struct inode *inode, struct file *filp)
> +{
> + int i;
> + struct dti_merged_view *view = filp->private_data;
> +
> + for_each_possible_cpu(i)
> +if (view->info[i].buf)
> + free_page((unsigned long)view->info[i].buf);
> +kfree(view);
use tab instead of spaces.
> +
> + return 0;
> +}
> +
> +static void *next_smallest(int *smallest_cpu, struct dti_merged_view *view )
>
[PATCH] splice: fix wrong __splice_from_pipe() usage
Hi,
I've noticed the nfsd read corruption by recent change. And this patch
fixes the problem for me, is this right fix?
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
__splice_from_pipe() is updating the sd->pos for the actor, but those
functions are passing the sd of reader side directory. So, splice
updates sd->pos twice.
This fixes usage of __splice_from_pipe().
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
drivers/block/loop.c |5 +++--
fs/nfsd/vfs.c|5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff -puN fs/nfsd/vfs.c~splice-fix-__splice_from_pipe-usage fs/nfsd/vfs.c
--- linux-2.6/fs/nfsd/vfs.c~splice-fix-__splice_from_pipe-usage 2007-07-16
09:30:10.0 +0900
+++ linux-2.6-hirofumi/fs/nfsd/vfs.c2007-07-16 09:30:10.0 +0900
@@ -842,9 +842,10 @@ nfsd_splice_actor(struct pipe_inode_info
}
static int nfsd_direct_splice_actor(struct pipe_inode_info *pipe,
- struct splice_desc *sd)
+ struct splice_desc *__sd)
{
- return __splice_from_pipe(pipe, sd, nfsd_splice_actor);
+ struct splice_desc sd = *__sd;
+ return __splice_from_pipe(pipe, , nfsd_splice_actor);
}
static __be32
diff -puN drivers/block/loop.c~splice-fix-__splice_from_pipe-usage
drivers/block/loop.c
--- linux-2.6/drivers/block/loop.c~splice-fix-__splice_from_pipe-usage
2007-07-16 09:30:10.0 +0900
+++ linux-2.6-hirofumi/drivers/block/loop.c 2007-07-16 09:30:10.0
+0900
@@ -437,9 +437,10 @@ lo_splice_actor(struct pipe_inode_info *
}
static int
-lo_direct_splice_actor(struct pipe_inode_info *pipe, struct splice_desc *sd)
+lo_direct_splice_actor(struct pipe_inode_info *pipe, struct splice_desc *__sd)
{
- return __splice_from_pipe(pipe, sd, lo_splice_actor);
+ struct splice_desc sd = *__sd;
+ return __splice_from_pipe(pipe, , lo_splice_actor);
}
static int
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fat: Fix the race of read/write the FAT12 entry
FAT12 entry is 12bits, so it needs 2 phase to update the value. And
writer and reader access it without any lock, so reader can get the
half updated value.
This fixes the long standing race condition by adding a global
spinlock to only FAT12 for avoiding any impact against FAT16/32.
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
fs/fat/fatent.c |7 +++
1 file changed, 7 insertions(+)
diff -puN fs/fat/fatent.c~fat_fat12-entry-race-fix fs/fat/fatent.c
--- linux-2.6/fs/fat/fatent.c~fat_fat12-entry-race-fix 2007-07-15
05:18:09.0 +0900
+++ linux-2.6-hirofumi/fs/fat/fatent.c 2007-07-15 05:18:56.0 +0900
@@ -17,6 +17,8 @@ struct fatent_operations {
int (*ent_next)(struct fat_entry *);
};
+static DEFINE_SPINLOCK(fat12_entry_lock);
+
static void fat12_ent_blocknr(struct super_block *sb, int entry,
int *offset, sector_t *blocknr)
{
@@ -116,10 +118,13 @@ static int fat12_ent_get(struct fat_entr
u8 **ent12_p = fatent->u.ent12_p;
int next;
+ spin_lock(_entry_lock);
if (fatent->entry & 1)
next = (*ent12_p[0] >> 4) | (*ent12_p[1] << 4);
else
next = (*ent12_p[1] << 8) | *ent12_p[0];
+ spin_unlock(_entry_lock);
+
next &= 0x0fff;
if (next >= BAD_FAT12)
next = FAT_ENT_EOF;
@@ -151,6 +156,7 @@ static void fat12_ent_put(struct fat_ent
if (new == FAT_ENT_EOF)
new = EOF_FAT12;
+ spin_lock(_entry_lock);
if (fatent->entry & 1) {
*ent12_p[0] = (new << 4) | (*ent12_p[0] & 0x0f);
*ent12_p[1] = new >> 4;
@@ -158,6 +164,7 @@ static void fat12_ent_put(struct fat_ent
*ent12_p[0] = new & 0xff;
*ent12_p[1] = (*ent12_p[1] & 0xf0) | (new >> 8);
}
+ spin_unlock(_entry_lock);
mark_buffer_dirty(fatent->bhs[0]);
if (fatent->nr_bhs == 2)
_
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Mon, 16 Jul 2007, Matthew Garrett wrote: On Sun, Jul 15, 2007 at 02:33:32PM +0200, Rafael J. Wysocki wrote: (snip) Many of these assumptions are based on the assumption that we want to save a full image of RAM. I'm not convinced that this is true. The two things that we need are application state and hardware state. Application state can clearly be saved without kernel involvement (though restoring some of it may need some help from the kernel...), so hardware state is a more interesting question. one other reason for saving all the ram is that some people want to save all the system caches so that the machine is just as responsive immediatly after the resume as it was before the hibernate. The obvious argument for saving the entirity of memory is that we have no mechanism for picking apart hardware state from any other part of the kernel. In reality, we're looking at implementing a set of hibernation operations anyway - it would be possible to utilise those to save as much state as needed. You also get fringe benefits, like being able to freeze a process that's accessing a piece of flaky hardware, swap the card out (assuming hotplug PCI), restore some amount of state and then let the process continue. I appreciate that this suggestion sounds kind of fragile and complicated, but I think that's true of most descriptions of suspend to disk :) The main benefit is that it means we can use the hibernation infrastructure for other purposes (checkpointing, swapping hardware, that kind of thing) and reduce the damage caused by users doing seemingly reasonable things (like suspending Linux, booting Windows and then writing to a shared partition...). I see the order being a little different. if anyone implements a reliable checkpoint/restore of applications then that could be used as to pause specific applicaitons, move applications from one machine to another, move applications from one kernel to another, and as a side effect, as a form of hibernation when you are willing to loose your cache in favor of storing as little info as possible (since you wouldn't need to store the cache memory or any kernel memory/state) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] [RESEND] sh updates for 2.6.23-rc1
Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git Which contains: Erik Johansson (1): sh: fix race in parallel out-of-tree build Kaz Kojima (1): sh: Fix up futex implementation. Kristoffer Ericson (3): sh: hd64461.h cleanup and added comments. sh: Kill off dead mach.c for hp6xx. sh: sh-rtc support for SH7709. Magnus Damm (2): sh: rework intc2 code sh: rework ipr code Nobuhiro Iwamatsu (2): sh: Add L-BOX RE2 to mach-types. sh: Fix timer-tmu build for SH-3. Paul Mundt (56): sh: Split out CPU topology initialization. sh: __user annotations for __get/__put_user(). sh: Fixup machvec support. sh: Shut up SH2-DSP compile warnings. sh: Rework CPU/board dependencies. sh: Fixup cmdline handling from machvec changes. sh: Get multiple boards in one image working again. sh: Kill off machvec aliases. sh: Rip out special unknown machvec. sh: Fix SH-4 CPU selects. sh: pfn_valid() depends on flatmem. sh: sparsemem support. sh: Allow for bootmem debug support. sh: Register multiple nodes in topology_init(). sh: Mark sparsemem regions present earlier. sh: Enable IPR-IRQ for SH7206. sh: Wrap CPU tuning through cc-option. sh: Tidy compiler warnings for SH-2A build. sh: Wire up mempolicy syscalls. sh: Default to 4-byte alignment for SLUB objects. sh: Fix up max_zone_pfns[] with multiple nodes. sh: Use asm/sections.h for linker section symbols. sh: Support for multiple nodes. sh: URAM node support for SH7722. sh: Make NUMA depend on sparsemem. sh: Fix the SH7722 flatmem build. sh: Fix up cpu to node mapping in sysfs. sh: memory hot-add for sparsemem users support. sh: Kill off dead SH7604 support. sh: Compile fix for SH7604 removal. sh: Tidy up dependencies for SH-2 build. sh: Fixup misaligned data for sh2 lockdep. fs: hugetlbfs: Disable for shnommu. sh: Kill off broken dma page ops. sh: Fix up the math-emu build. sh: Only support PMB for SH-X cores. sh: Update SH-2/SH-2A defconfigs. sh: Check oops_may_print() in unhandled fault. sh: Fix up cf-enabler dependency for SE boards. sh: Update se7722 defconfig. sh: Hook up hard_smp_processor_id() for INTC2 block. sh: Preliminary support for the SH-X3 CPU. Merge branch 'x3' sh: Add cpu and mach links to CLEAN_FILES. sh: Correct __xdiv64_32/div64_32 return value size. sh: Select IPR-IRQ for SH7091. fb: pvr2fb: Fix up section mismatch warnings. fb: pvr2fb: A few more __devinit annotations for PCI. sh: Update dreamcast defconfig. sh: Drop -Wa,-dsp for DSP tuning. sh: Add parport stub for SuperIO ports. sh: Don't let SH-4A clobber SH-4 CFLAGS. sh: Add a .bss.page_aligned section for 4K stacks. sh: Export div symbols for GCC 4.2 and ST GCC. sh: Update r7785rp defconfig. sh: Revert __xdiv64_32 size change. Robert P. J. Day (2): sh: Warn against direct inclusion of . sh: Update the alignment when 4K stacks are used. Takashi YOSHII (1): sh: Align .machvec.init section on a 4-byte boundary. Yoshihiro Shimoda (1): sh: Provide a defconfig for R7780MP. arch/sh/Kconfig | 441 +- arch/sh/Kconfig.debug |5 arch/sh/Makefile| 104 +- arch/sh/boards/dreamcast/setup.c|3 arch/sh/boards/hp6xx/mach.c | 46 - arch/sh/boards/hp6xx/setup.c|3 arch/sh/boards/landisk/setup.c |3 arch/sh/boards/lboxre2/setup.c |3 arch/sh/boards/mpc1211/setup.c |3 arch/sh/boards/renesas/edosk7705/setup.c|3 arch/sh/boards/renesas/hs7751rvoip/setup.c |3 arch/sh/boards/renesas/r7780rp/Kconfig |6 arch/sh/boards/renesas/r7780rp/setup.c |3 arch/sh/boards/renesas/rts7751r2d/setup.c |3 arch/sh/boards/renesas/sh7710voipgw/setup.c |3 arch/sh/boards/renesas/systemh/setup.c |3 arch/sh/boards/saturn/Makefile |8 arch/sh/boards/saturn/io.c | 26 arch/sh/boards/saturn/irq.c | 118 -- arch/sh/boards/saturn/setup.c | 31 arch/sh/boards/saturn/smp.c | 68 - arch/sh/boards/se/7206/setup.c |3 arch/sh/boards/se/7300/setup.c |3 arch/sh/boards/se/73180/setup.c |3 arch/sh/boards/se/7343/setup.c |3 arch/sh/boards/se/7619/setup.c |3 arch/sh/boards/se/770x/irq.c| 124 +- arch/sh/boards/se/770x/setup.c |3 arch/sh/boards/se/7722/irq.c| 15 arch/sh/boards/se/7722/setup.c |3
Re: Hibernation considerations
On Sun, Jul 15, 2007 at 02:33:32PM +0200, Rafael J. Wysocki wrote: (snip) Many of these assumptions are based on the assumption that we want to save a full image of RAM. I'm not convinced that this is true. The two things that we need are application state and hardware state. Application state can clearly be saved without kernel involvement (though restoring some of it may need some help from the kernel...), so hardware state is a more interesting question. The obvious argument for saving the entirity of memory is that we have no mechanism for picking apart hardware state from any other part of the kernel. In reality, we're looking at implementing a set of hibernation operations anyway - it would be possible to utilise those to save as much state as needed. You also get fringe benefits, like being able to freeze a process that's accessing a piece of flaky hardware, swap the card out (assuming hotplug PCI), restore some amount of state and then let the process continue. I appreciate that this suggestion sounds kind of fragile and complicated, but I think that's true of most descriptions of suspend to disk :) The main benefit is that it means we can use the hibernation infrastructure for other purposes (checkpointing, swapping hardware, that kind of thing) and reduce the damage caused by users doing seemingly reasonable things (like suspending Linux, booting Windows and then writing to a shared partition...). -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[M68KNOMMU]: generic irq handling
Change the m68knommu irq handling to use the generic irq framework.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
arch/m68knommu/Kconfig |4
arch/m68knommu/kernel/Makefile |4
arch/m68knommu/kernel/asm-offsets.c|5
arch/m68knommu/kernel/irq.c| 82 +
arch/m68knommu/kernel/traps.c |2
arch/m68knommu/platform/5307/Makefile |2
arch/m68knommu/platform/5307/entry.S | 47 +
arch/m68knommu/platform/5307/ints.c| 279 -
arch/m68knommu/platform/5307/vectors.c | 29 ++-
arch/m68knommu/platform/68328/entry.S | 10 -
arch/m68knommu/platform/68328/ints.c | 130 ++-
arch/m68knommu/platform/68360/entry.S |6
arch/m68knommu/platform/68360/ints.c | 233 +--
include/asm-m68knommu/irq.h| 75
include/asm-m68knommu/irqnode.h| 36
include/asm-m68knommu/m68360.h |8
include/asm-m68knommu/traps.h |4
17 files changed, 176 insertions(+), 780 deletions(-)
diff -Naur linux-2.6.22/arch/m68knommu/Kconfig
linux-2.6.22-uc0/arch/m68knommu/Kconfig
--- linux-2.6.22/arch/m68knommu/Kconfig 2007-07-12 15:23:02.0 +1000
+++ linux-2.6.22-uc0/arch/m68knommu/Kconfig 2007-07-12 15:27:03.0
+1000
@@ -45,6 +45,10 @@
bool
default y
+config GENERIC_HARDIRQS
+ bool
+ default y
+
config GENERIC_CALIBRATE_DELAY
bool
default y
diff -Naur linux-2.6.22/arch/m68knommu/kernel/asm-offsets.c
linux-2.6.22-uc0/arch/m68knommu/kernel/asm-offsets.c
--- linux-2.6.22/arch/m68knommu/kernel/asm-offsets.c2007-07-12
15:23:02.0 +1000
+++ linux-2.6.22-uc0/arch/m68knommu/kernel/asm-offsets.c2007-07-12
15:27:00.0 +1000
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#define DEFINE(sym, val) \
@@ -72,10 +71,6 @@
#else
/* bitfields are a bit difficult */
DEFINE(PT_VECTOR, offsetof(struct pt_regs, pc) + 4);
- /* offsets into the irq_handler struct */
- DEFINE(IRQ_HANDLER, offsetof(struct irq_node, handler));
- DEFINE(IRQ_DEVID, offsetof(struct irq_node, dev_id));
- DEFINE(IRQ_NEXT, offsetof(struct irq_node, next));
#endif
/* offsets into the kernel_stat struct */
diff -Naur linux-2.6.22/arch/m68knommu/kernel/irq.c
linux-2.6.22-uc0/arch/m68knommu/kernel/irq.c
--- linux-2.6.22/arch/m68knommu/kernel/irq.c1970-01-01 10:00:00.0
+1000
+++ linux-2.6.22-uc0/arch/m68knommu/kernel/irq.c2007-07-12
15:27:00.0 +1000
@@ -0,0 +1,82 @@
+/*
+ * irq.c
+ *
+ * (C) Copyright 2007, Greg Ungerer <[EMAIL PROTECTED]>
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+asmlinkage void do_IRQ(int irq, struct pt_regs *regs)
+{
+ struct pt_regs *oldregs = set_irq_regs(regs);
+
+ irq_enter();
+ __do_IRQ(irq);
+ irq_exit();
+
+ set_irq_regs(oldregs);
+}
+
+void ack_bad_irq(unsigned int irq)
+{
+ printk(KERN_ERR "IRQ: unexpected irq=%d\n", irq);
+}
+
+static struct irq_chip m_irq_chip = {
+ .name = "M68K-INTC",
+ .enable = enable_vector,
+ .disable= disable_vector,
+ .ack= ack_vector,
+};
+
+void __init init_IRQ(void)
+{
+ int irq;
+
+ init_vectors();
+
+ for (irq = 0; (irq < NR_IRQS); irq++) {
+ irq_desc[irq].status = IRQ_DISABLED;
+ irq_desc[irq].action = NULL;
+ irq_desc[irq].depth = 1;
+ irq_desc[irq].chip = _irq_chip;
+ }
+}
+
+int show_interrupts(struct seq_file *p, void *v)
+{
+ struct irqaction *ap;
+ int irq = *((loff_t *) v);
+
+ if (irq == 0)
+ seq_puts(p, " CPU0\n");
+
+ if (irq < NR_IRQS) {
+ ap = irq_desc[irq].action;
+ if (ap) {
+ seq_printf(p, "%3d: ", irq);
+ seq_printf(p, "%10u ", kstat_irqs(irq));
+ seq_printf(p, "%14s ", irq_desc[irq].chip->name);
+
+ seq_printf(p, "%s", ap->name);
+ for (ap = ap->next; ap; ap = ap->next)
+ seq_printf(p, ", %s", ap->name);
+ seq_putc(p, '\n');
+ }
+ }
+
+ return 0;
+}
+
diff -Naur linux-2.6.22/arch/m68knommu/kernel/Makefile
linux-2.6.22-uc0/arch/m68knommu/kernel/Makefile
--- linux-2.6.22/arch/m68knommu/kernel/Makefile 2007-07-12 15:23:02.0
+1000
+++ linux-2.6.22-uc0/arch/m68knommu/kernel/Makefile 2007-07-12
15:27:00.0 +1000
@@ -4,8 +4,8 @@
extra-y := vmlinux.lds
-obj-y += dma.o entry.o init_task.o
[M68KNOMMU]: start dump from exception stack
In die_if_kernel() start the stack dump at the exception-time SP, not at the SP with all the saved registers; the stack below exception-time sp contains only exception-saved values and is already printed in details just before. Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]> Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur linux-2.6.22/arch/m68knommu/kernel/traps.c linux-2.6.22-uc0/arch/m68knommu/kernel/traps.c --- linux-2.6.22/arch/m68knommu/kernel/traps.c 2007-07-12 15:23:02.0 +1000 +++ linux-2.6.22-uc0/arch/m68knommu/kernel/traps.c 2007-07-12 15:27:00.0 +1000 @@ -82,7 +80,7 @@ printk(KERN_EMERG "Process %s (pid: %d, stackpage=%08lx)\n", current->comm, current->pid, PAGE_SIZE+(unsigned long)current); - show_stack(NULL, (unsigned long *)fp); + show_stack(NULL, (unsigned long *)(fp+1)); do_exit(SIGSEGV); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[M68KNOMMU]: remove is_in_rom() function
Remove is_in_rom() function. It doesn't actually serve the purpose it was
intended to. If you look at the use of it _access_ok() (which is the only
use of it) then it is obvious that most of memory is marked as access_ok.
No point having is_in_rom() then, so remove it.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naur linux-2.6.22/arch/m68knommu/mm/memory.c
linux-2.6.22-uc0/arch/m68knommu/mm/memory.c
--- linux-2.6.22/arch/m68knommu/mm/memory.c 2007-07-12 15:23:02.0
+1000
+++ linux-2.6.22-uc0/arch/m68knommu/mm/memory.c 2007-07-12 15:27:04.0
+1000
@@ -109,23 +33,3 @@
return paddr;
}
-
-int is_in_rom(unsigned long addr)
-{
- extern unsigned long _ramstart, _ramend;
-
- /*
-* What we are really trying to do is determine if addr is
-* in an allocated kernel memory region. If not then assume
-* we cannot free it or otherwise de-allocate it. Ideally
-* we could restrict this to really being in a ROM or flash,
-* but that would need to be done on a board by board basis,
-* not globally.
-*/
- if ((addr < _ramstart) || (addr >= _ramend))
- return(1);
-
- /* Default case, not in ROM */
- return(0);
-}
-
diff -Naur linux-2.6.22/arch/m68knommu/kernel/m68k_ksyms.c
linux-2.6.22-uc0/arch/m68knommu/kernel/m68k_ksyms.c
--- linux-2.6.22/arch/m68knommu/kernel/m68k_ksyms.c 2007-07-12
15:23:02.0 +1000
+++ linux-2.6.22-uc0/arch/m68knommu/kernel/m68k_ksyms.c 2007-07-12
15:27:00.0 +1000
@@ -81,8 +81,6 @@
EXPORT_SYMBOL(__udivsi3);
EXPORT_SYMBOL(__umodsi3);
-EXPORT_SYMBOL(is_in_rom);
-
#ifdef CONFIG_COLDFIRE
extern unsigned int *dma_device_address;
extern unsigned long dma_base_addr, _ramend;
diff -Naur linux-2.6.22/include/asm-m68knommu/pgtable.h
linux-2.6.22-uc0/include/asm-m68knommu/pgtable.h
--- linux-2.6.22/include/asm-m68knommu/pgtable.h2007-07-12
15:21:55.0 +1000
+++ linux-2.6.22-uc0/include/asm-m68knommu/pgtable.h2007-07-12
15:23:58.0 +1000
@@ -49,7 +49,6 @@
* These would be in other places but having them here reduces the diffs.
*/
extern unsigned int kobjsize(const void *objp);
-extern int is_in_rom(unsigned long);
/*
* No page table caches to initialise.
diff -Naur linux-2.6.22/include/asm-m68knommu/uaccess.h
linux-2.6.22-uc0/include/asm-m68knommu/uaccess.h
--- linux-2.6.22/include/asm-m68knommu/uaccess.h2007-07-12
15:21:55.0 +1000
+++ linux-2.6.22-uc0/include/asm-m68knommu/uaccess.h2007-07-12
15:23:59.0 +1000
@@ -15,12 +15,15 @@
#define access_ok(type,addr,size) _access_ok((unsigned long)(addr),(size))
+/*
+ * It is not enough to just have access_ok check for a real RAM address.
+ * This would disallow the case of code/ro-data running XIP in flash/rom.
+ * Ideally we would check the possible flash ranges too, but that is
+ * currently not so easy.
+ */
static inline int _access_ok(unsigned long addr, unsigned long size)
{
- extern unsigned long memory_start, memory_end;
-
- return (((addr >= memory_start) && (addr+size < memory_end)) ||
- (is_in_rom(addr) && is_in_rom(addr+size)));
+ return 1;
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[M68KNOMMU]: remove cruft from setup code
Clean up the m68knommu/kernel/setup.c. It is just full of old junk.
. removed unused includes
. removed unused conditional code (with unused defines)
. removed unused code
. removed unused function prototypes and variables
. remove old/wrong comments
. retabed code that was inconsistently formated
. correct copyrights
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naur linux-2.6.22/arch/m68knommu/kernel/setup.c
linux-2.6.22-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.22/arch/m68knommu/kernel/setup.c 2007-07-12 15:23:02.0
+1000
+++ linux-2.6.22-uc0/arch/m68knommu/kernel/setup.c 2007-07-12
15:27:00.0 +1000
@@ -1,8 +1,8 @@
/*
* linux/arch/m68knommu/kernel/setup.c
*
- * Copyright (C) 1999-2004 Greg Ungerer ([EMAIL PROTECTED])
- * Copyright (C) 1998,1999 D. Jeff Dionne <[EMAIL PROTECTED]>
+ * Copyright (C) 1999-2007 Greg Ungerer ([EMAIL PROTECTED])
+ * Copyright (C) 1998,1999 D. Jeff Dionne <[EMAIL PROTECTED]>
* Copyleft ()) 2000 James D. Schettine [EMAIL PROTECTED]
* Copyright (C) 1998 Kenneth Albanowski <[EMAIL PROTECTED]>
* Copyright (C) 1995 Hamish Macdonald
@@ -20,17 +20,13 @@
#include
#include
#include
-#include
#include
#include
#include
-#include
#include
#include
-#include
#include
#include
-#include
#include
#include
@@ -46,34 +42,14 @@
char __initdata command_line[COMMAND_LINE_SIZE];
-/* setup some dummy routines */
-static void dummy_waitbut(void)
-{
-}
-
-void (*mach_sched_init) (irq_handler_t handler);
-void (*mach_tick)( void );
-/* machine dependent keyboard functions */
-int (*mach_keyb_init) (void);
-int (*mach_kbdrate) (struct kbd_repeat *);
-void (*mach_kbd_leds) (unsigned int);
-/* machine dependent irq functions */
-void (*mach_init_IRQ) (void);
-irq_handler_t mach_default_handler;
-int (*mach_get_irq_list) (struct seq_file *, void *);
-void (*mach_process_int) (int irq, struct pt_regs *fp);
-void (*mach_trap_init) (void);
/* machine dependent timer functions */
-unsigned long (*mach_gettimeoffset) (void);
-void (*mach_gettod) (int*, int*, int*, int*, int*, int*);
-int (*mach_hwclk) (int, struct rtc_time*);
-int (*mach_set_clock_mmss) (unsigned long);
-void (*mach_mksound)( unsigned int count, unsigned int ticks );
-void (*mach_reset)( void );
-void (*waitbut)(void) = dummy_waitbut;
-void (*mach_debug_init)(void);
-void (*mach_halt)( void );
-void (*mach_power_off)( void );
+void (*mach_gettod)(int*, int*, int*, int*, int*, int*);
+int (*mach_set_clock_mmss)(unsigned long);
+
+/* machine dependent reboot functions */
+void (*mach_reset)(void);
+void (*mach_halt)(void);
+void (*mach_power_off)(void);
#ifdef CONFIG_M68000
@@ -134,13 +110,6 @@
#define CPU "UNKNOWN"
#endif
-/* (es) */
-/* note: why is this defined here? the must be a better place to put this */
-#if defined( CONFIG_TELOS) || defined( CONFIG_UCDIMM ) || defined(
CONFIG_UCSIMM ) || defined(CONFIG_DRAGEN2) || (defined( CONFIG_PILOT ) &&
defined( CONFIG_M68328 ))
-#define CAT_ROMARRAY
-#endif
-/* (/es) */
-
extern int _stext, _etext, _sdata, _edata, _sbss, _ebss, _end;
extern int _ramstart, _ramend;
@@ -148,15 +117,8 @@
{
int bootmap_size;
-#if defined(CAT_ROMARRAY) && defined(DEBUG)
- extern int __data_rom_start;
- extern int __data_start;
- int *romarray = (int *)((int) &__data_rom_start +
- (int)&_edata - (int)&__data_start);
-#endif
-
memory_start = PAGE_ALIGN(_ramstart);
- memory_end = _ramend; /* by now the stack is part of the init task */
+ memory_end = _ramend;
init_mm.start_code = (unsigned long) &_stext;
init_mm.end_code = (unsigned long) &_etext;
@@ -218,15 +185,9 @@
"BSS=0x%06x-0x%06x\n", (int) &_stext, (int) &_etext,
(int) &_sdata, (int) &_edata,
(int) &_sbss, (int) &_ebss);
- printk(KERN_DEBUG "KERNEL -> ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x "
- "STACK=0x%06x-0x%06x\n",
-#ifdef CAT_ROMARRAY
- (int) romarray, ((int) romarray) + romarray[2],
-#else
+ printk(KERN_DEBUG "MEMORY -> ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x\n ",
(int) &_ebss, (int) memory_start,
-#endif
- (int) memory_start, (int) memory_end,
- (int) memory_end, (int) _ramend);
+ (int) memory_start, (int) memory_end);
#endif
/* Keep a copy of command line */
@@ -268,32 +229,33 @@
/*
* Get CPU information for use by the procfs.
*/
-
static int show_cpuinfo(struct seq_file *m, void *v)
{
-char *cpu, *mmu, *fpu;
-u_long clockfreq;
+ char *cpu, *mmu, *fpu;
+ u_long clockfreq;
-cpu = CPU;
-mmu = "none";
-fpu = "none";
+ cpu = CPU;
+ mmu = "none";
+ fpu = "none";
#ifdef CONFIG_COLDFIRE
-clockfreq = (loops_per_jiffy*HZ)*3;
+ clockfreq = (loops_per_jiffy * HZ) * 3;
#else
-clockfreq =
[M68KNOMMU]: use TRHEAD_SIZE instead of hard constant
Use THREAD_SIZE instead of a hard constant.
Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naur linux-2.6.22/arch/m68knommu/kernel/process.c
linux-2.6.22-uc0/arch/m68knommu/kernel/process.c
--- linux-2.6.22/arch/m68knommu/kernel/process.c2007-07-12
15:23:02.0 +1000
+++ linux-2.6.22-uc0/arch/m68knommu/kernel/process.c2007-07-12
15:27:00.0 +1000
@@ -377,7 +377,7 @@
fp = ((struct switch_stack *)p->thread.ksp)->a6;
do {
if (fp < stack_page+sizeof(struct thread_info) ||
- fp >= 8184+stack_page)
+ fp >= THREAD_SIZE-8+stack_page)
return 0;
pc = ((unsigned long *)fp)[1];
if (!in_sched_functions(pc))
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[M68KNOMMU]: remove old cache management cruft
Remove cache management cruft. This code is dead, all the cache
manangement functions for the ColdFire exist in the header file
include/asm-m68knommu/cacheflush.h.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naur linux-2.6.22/arch/m68knommu/mm/memory.c
linux-2.6.22-uc0/arch/m68knommu/mm/memory.c
--- linux-2.6.22/arch/m68knommu/mm/memory.c 2007-07-12 15:23:02.0
+1000
+++ linux-2.6.22-uc0/arch/m68knommu/mm/memory.c 2007-07-12 15:27:04.0
+1000
@@ -17,90 +17,14 @@
#include
#include
-#include
#include
#include
#include
#include
-#include
-#include
/*
- * cache_clear() semantics: Clear any cache entries for the area in question,
- * without writing back dirty entries first. This is useful if the data will
- * be overwritten anyway, e.g. by DMA to memory. The range is defined by a
- * _physical_ address.
- */
-
-void cache_clear (unsigned long paddr, int len)
-{
-}
-
-
-/*
- * Define cache invalidate functions. The ColdFire 5407 is really
- * the only processor that needs to do some work here. Anything
- * that has separate data and instruction caches will be a problem.
- */
-#ifdef CONFIG_M5407
-
-static __inline__ void cache_invalidate_lines(unsigned long paddr, int len)
-{
- unsigned long sset, eset;
-
- sset = (paddr & 0x0ff0);
- eset = ((paddr + len) & 0xff0) + 0x10;
-
- __asm__ __volatile__ (
- "nop\n\t"
- "clrl %%d0\n\t"
- "1:\n\t"
- "movel %0,%%a0\n\t"
- "addl %%d0,%%a0\n\t"
- "2:\n\t"
- ".word 0xf4e8\n\t"
- "addl #0x10,%%a0\n\t"
- "cmpl %1,%%a0\n\t"
- "blt2b\n\t"
- "addql #1,%%d0\n\t"
- "cmpil #4,%%d0\n\t"
- "bne1b"
- : : "a" (sset), "a" (eset) : "d0", "a0" );
-}
-
-#else
-#definecache_invalidate_lines(a,b)
-#endif
-
-
-/*
- * cache_push() semantics: Write back any dirty cache data in the given area,
- * and invalidate the range in the instruction cache. It needs not (but may)
- * invalidate those entries also in the data cache. The range is defined by a
- * _physical_ address.
- */
-
-void cache_push (unsigned long paddr, int len)
-{
- cache_invalidate_lines(paddr, len);
-}
-
-
-/*
- * cache_push_v() semantics: Write back any dirty cache data in the given
- * area, and invalidate those entries at least in the instruction cache. This
- * is intended to be used after data has been written that can be executed as
- * code later. The range is defined by a _user_mode_ _virtual_ address (or,
- * more exactly, the space is defined by the %sfc/%dfc register.)
- */
-
-void cache_push_v (unsigned long vaddr, int len)
-{
- cache_invalidate_lines(vaddr, len);
-}
-
-/* Map some physical address range into the kernel address space. The
- * code is copied and adapted from map_chunk().
+ * Map some physical address range into the kernel address space.
+ * The code is copied and adapted from map_chunk().
*/
unsigned long kernel_map(unsigned long paddr, unsigned long size,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[NOMMU]: stub expand_stack() for nommu case
Be consistent with VM mmap, implement expand_stack().
We can't actually do anything other than return an error
in the no MMU case though.
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---
diff -Naur linux-2.6.22/mm/nommu.c linux-2.6.22-uc0/mm/nommu.c
--- linux-2.6.22/mm/nommu.c 2007-07-12 15:22:07.0 +1000
+++ linux-2.6.22-uc0/mm/nommu.c 2007-07-12 15:24:21.0 +1000
@@ -367,6 +367,11 @@
return find_vma(mm, addr);
}
+int expand_stack(struct vm_area_struct *vma, unsigned long address)
+{
+ return -ENOMEM;
+}
+
/*
* look up the first VMA exactly that exactly matches addr
* - should be called with mm->mmap_sem at least held readlocked
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/8] Immediate Value - Add kconfig menus
* Andi Kleen ([EMAIL PROTECTED]) wrote: > > On embedded systems, the tradeoff is not the same. The immediate values > > trade a little bit of system memory (to keep the pointers to the > > variable and instruction as well as the size of the variable, only used > > when the variable is updated) in order to remove cache line hot paths. > > Please remove the Kconfig. I don't think it makes sense. Such optimizations > should be always enabled. We don't have CONFIG_GO_FASTER configs normally. > Don't introduce them now. > > > > > Also, embedded systems with physically read-only memory clearly does not > > want to enable this. > > We always patch the x86 kernel, so they have to deal with it anyways. > The x86 port doesn't support XIP. > > -Andi Hehe, good timing, please see the immediate-values-kconfig-embedded.patch I just sent. ;) Well, the idea is to give the option to every architecture in the embedded menu, which is not limited to X86. -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix return type of skb_checksum_complete()
From: Al Viro <[EMAIL PROTECTED]> Date: Sun, 15 Jul 2007 21:00:11 +0100 > > It returns __sum16, not unsigned int > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fallout from constified seq_operations
From: Al Viro <[EMAIL PROTECTED]> Date: Sun, 15 Jul 2007 21:01:12 +0100 > > Signed-off-by: Al Viro <[EMAIL PROTECTED]> Acked-by: David S. Miller <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Add KERN_* prefix to printks in bug.h
---
include/asm-generic/bug.h | 25 +
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 7f30cce..6e49266 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -8,22 +8,23 @@
#ifdef CONFIG_GENERIC_BUG
#ifndef __ASSEMBLY__
struct bug_entry {
- unsigned long bug_addr;
+ unsigned long bug_addr;
#ifdef CONFIG_DEBUG_BUGVERBOSE
- const char *file;
- unsigned short line;
+ const char *file;
+ unsigned short line;
#endif
- unsigned short flags;
+ unsigned short flags;
};
-#endif /* __ASSEMBLY__ */
+#endif /* __ASSEMBLY__ */
#define BUGFLAG_WARNING(1<<0)
-#endif /* CONFIG_GENERIC_BUG */
+#endif /* CONFIG_GENERIC_BUG */
#ifndef HAVE_ARCH_BUG
-#define BUG() do { \
- printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__,
__FUNCTION__); \
- panic("BUG!"); \
+#define BUG() do { \
+ printk(KERN_EMERG "BUG: failure at %s:%d/%s()!\n", \
+ __FILE__, __LINE__, __FUNCTION__); \
+ panic("BUG!"); \
} while (0)
#endif
@@ -35,15 +36,15 @@ struct bug_entry {
#define WARN_ON(condition) ({ \
typeof(condition) __ret_warn_on = (condition); \
if (unlikely(__ret_warn_on)) { \
- printk("WARNING: at %s:%d %s()\n", __FILE__,\
- __LINE__, __FUNCTION__);\
+ printk(KERN_WARNING "WARNING: at %s:%d %s()\n", \
+ __FILE__, __LINE__, __FUNCTION__); \
dump_stack(); \
} \
unlikely(__ret_warn_on);\
})
#endif
-#else /* !CONFIG_BUG */
+#else /* !CONFIG_BUG */
#ifndef HAVE_ARCH_BUG
#define BUG()
#endif
--
1.5.2.3
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Crypto Update for 2.6.23
From: Herbert Xu <[EMAIL PROTECTED]> Date: Sun, 15 Jul 2007 21:15:57 +0800 > On Sat, Jul 14, 2007 at 11:48:39PM -0700, David Miller wrote: > > Herbert can you contact the async_tx author to make sure that > > his crypto/ bits go through you in the future so that conflicts > > like this can be avoided? > > No problems. This was a once-off because it involved multiple > conflicts all over the place as Andrew can no doubt attest to :) I kind of figured as much since it had dependencies on other subsystems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] [GIT PULL] 9p Patches for 2.6.23 merge window
On Sun, 15 Jul 2007, Latchesar Ionkov wrote:
I thought that it is not a good idea to keep the v9fs_ prefix for code
that is in different places (fs/9p and net/9p). If keeping the old
prefix is more acceptable, I can create a new patch without the
"v9fs_"->"p9_" renames.
do the code reorg and the name changes as two different patches. it makes
it much easier to see that the rename doesn't change any functionality,
and makes the code reorg much easier to see.
David Lang
Thanks,
Lucho
On 7/15/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Sat, 14 Jul 2007, Eric Van Hensbergen wrote:
>
> The bulk of the changes were in the reorganization patch which mostly
> moved files and interfaces around in preparation for work on an
> in-kernel 9p server.
Please use "git diff -C --stat --summary" to generate the diffstat
summary.
In particular, because you didn't use -C (or -M), git have you an
old-style diffstat without renames, so the diffstat doesn't show that a
lot of it was moving code around.
(That said, you seem to have changed names a lot too, so it's not pure
code movement).
> 49 files changed, 5400 insertions(+), 5092 deletions(-)
With rename detection enabled, I get
36 files changed, 3444 insertions(+), 3130 deletions(-)
due to finding some (partially dubious) renames:
rename fs/9p/mux.h => include/net/9p/conn.h (53%)
rename {fs => include/net}/9p/transport.h (59%)
rename {fs => net}/9p/conv.c (55%)
rename {fs => net}/9p/fcprint.c (64%)
rename {fs => net}/9p/mux.c (55%)
even though is misses a lot of others (due to all the "v9fs" -> "p9"
changes in the source code too - was that really worth it?).
Linus
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
V9fs-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/v9fs-developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/8] Immediate Value - Add kconfig menus
> On embedded systems, the tradeoff is not the same. The immediate values > trade a little bit of system memory (to keep the pointers to the > variable and instruction as well as the size of the variable, only used > when the variable is updated) in order to remove cache line hot paths. Please remove the Kconfig. I don't think it makes sense. Such optimizations should be always enabled. We don't have CONFIG_GO_FASTER configs normally. Don't introduce them now. > > Also, embedded systems with physically read-only memory clearly does not > want to enable this. We always patch the x86 kernel, so they have to deal with it anyways. The x86 port doesn't support XIP. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Immediate Value - Kconfig menu in EMBEDDED
Immediate Values - Kconfig menu in EMBEDDED Immediate values provide a way to use dynamic code patching to update variables sitting within the instruction stream. It saves caches lines normally used by static read mostly variables. Enable it by default, but let users disable it through the EMBEDDED menu with the "Disable immediate values" submenu entry. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Adrian Bunk <[EMAIL PROTECTED]> CC: Andi Kleen <[EMAIL PROTECTED]> CC: Alexey Dobriyan <[EMAIL PROTECTED]> CC: Christoph Hellwig <[EMAIL PROTECTED]> --- init/Kconfig | 21 + 1 file changed, 21 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-07-15 20:09:53.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-07-15 20:23:16.0 -0400 @@ -410,6 +410,17 @@ config CC_OPTIMIZE_FOR_SIZE config SYSCTL bool +config IMMEDIATE + default y if !DISABLE_IMMEDIATE + depends on X86_32 || PPC + bool + help + Immediate values are used as read mostly variables that are rarely + updated. They use code patching to modify the values inscribed in the + instruction stream. It provides a way to save precious cache lines + that would otherwise have to be used by these variables. Can be + disabled through the EMBEDDED menu. + menuconfig EMBEDDED bool "Configure standard kernel features (for small systems)" help @@ -672,6 +683,16 @@ config PROC_KPAGEMAP information on page-level memory usage. Disabling this interface will reduce the size of the kernel for small machines. +config DISABLE_IMMEDIATE + default y if EMBEDDED + bool "Disable immediate values" if EMBEDDED + depends on X86_32 || PPC + help + Disable code patching based immediate values for embedded systems. It + consumes slightly more memory and requires to modify the instruction + stream each time a variable is updated. Should really be disabled for + embedded systems with read-only text. + endmenu# General setup config RT_MUTEXES -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 4/8] Immediate Value - Add kconfig menus
Should be dropped, replaced by : immediate-values-kconfig-embedded.patch * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: > Immediate values provide a way to use dynamic code patching to update > variables > sitting within the instruction stream. It saves caches lines normally used by > static read mostly variables. > > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> > CC: Adrian Bunk <[EMAIL PROTECTED]> > CC: Andi Kleen <[EMAIL PROTECTED]> > --- > > arch/alpha/Kconfig |6 ++ > arch/arm/Kconfig |6 ++ > arch/arm26/Kconfig |6 ++ > arch/avr32/Kconfig.debug |7 +++ > arch/cris/Kconfig|6 ++ > arch/frv/Kconfig |6 ++ > arch/h8300/Kconfig |6 ++ > arch/i386/Kconfig|2 ++ > arch/ia64/Kconfig|3 +++ > arch/m32r/Kconfig|6 ++ > arch/m68k/Kconfig|6 ++ > arch/m68knommu/Kconfig |6 ++ > arch/mips/Kconfig|6 ++ > arch/parisc/Kconfig |6 ++ > arch/powerpc/Kconfig |3 +++ > arch/ppc/Kconfig |6 ++ > arch/s390/Kconfig|2 ++ > arch/sh/Kconfig |6 ++ > arch/sh64/Kconfig|6 ++ > arch/sparc/Kconfig |2 ++ > arch/sparc64/Kconfig |3 +++ > arch/um/Kconfig |6 ++ > arch/v850/Kconfig|6 ++ > arch/x86_64/Kconfig |3 +++ > arch/xtensa/Kconfig |6 ++ > kernel/Kconfig.immediate | 11 +++ > 26 files changed, 138 insertions(+) > > Index: linux-2.6-lttng/arch/alpha/Kconfig > === > --- linux-2.6-lttng.orig/arch/alpha/Kconfig 2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/alpha/Kconfig2007-07-13 14:33:51.0 > -0400 > @@ -653,6 +653,12 @@ > > source "arch/alpha/oprofile/Kconfig" > > +menu "Instrumentation Support" > + > +source "kernel/Kconfig.immediate" > + > +endmenu > + > source "arch/alpha/Kconfig.debug" > > # DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig > Index: linux-2.6-lttng/arch/arm/Kconfig > === > --- linux-2.6-lttng.orig/arch/arm/Kconfig 2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/arm/Kconfig 2007-07-13 14:33:51.0 -0400 > @@ -1046,6 +1046,12 @@ > > source "arch/arm/oprofile/Kconfig" > > +menu "Instrumentation Support" > + > +source "kernel/Kconfig.immediate" > + > +endmenu > + > source "arch/arm/Kconfig.debug" > > source "security/Kconfig" > Index: linux-2.6-lttng/arch/arm26/Kconfig > === > --- linux-2.6-lttng.orig/arch/arm26/Kconfig 2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/arm26/Kconfig2007-07-13 14:33:51.0 > -0400 > @@ -244,6 +244,12 @@ > > source "drivers/usb/Kconfig" > > +menu "Instrumentation Support" > + > +source "kernel/Kconfig.immediate" > + > +endmenu > + > source "arch/arm26/Kconfig.debug" > > source "security/Kconfig" > Index: linux-2.6-lttng/arch/cris/Kconfig > === > --- linux-2.6-lttng.orig/arch/cris/Kconfig2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/cris/Kconfig 2007-07-13 14:33:51.0 -0400 > @@ -198,6 +198,12 @@ > > source "drivers/usb/Kconfig" > > +menu "Instrumentation Support" > + > +source "kernel/Kconfig.immediate" > + > +endmenu > + > source "arch/cris/Kconfig.debug" > > source "security/Kconfig" > Index: linux-2.6-lttng/arch/frv/Kconfig > === > --- linux-2.6-lttng.orig/arch/frv/Kconfig 2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/frv/Kconfig 2007-07-13 14:33:51.0 -0400 > @@ -375,6 +375,12 @@ > > source "fs/Kconfig" > > +menu "Instrumentation Support" > + > +source "kernel/Kconfig.immediate" > + > +endmenu > + > source "arch/frv/Kconfig.debug" > > source "security/Kconfig" > Index: linux-2.6-lttng/arch/h8300/Kconfig > === > --- linux-2.6-lttng.orig/arch/h8300/Kconfig 2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/h8300/Kconfig2007-07-13 14:33:51.0 > -0400 > @@ -223,6 +223,12 @@ > > source "fs/Kconfig" > > +menu "Instrumentation Support" > + > +source "kernel/Kconfig.immediate" > + > +endmenu > + > source "arch/h8300/Kconfig.debug" > > source "security/Kconfig" > Index: linux-2.6-lttng/arch/i386/Kconfig > === > --- linux-2.6-lttng.orig/arch/i386/Kconfig2007-07-13 14:17:59.0 > -0400 > +++ linux-2.6-lttng/arch/i386/Kconfig 2007-07-13 14:33:51.0 -0400 > @@ -1249,6 +1249,8 @@ > for kernel debugging,
Re: panics with 16port Promise Supertrack EX Controller
On Mon, 16 Jul 2007 00:51:55 +0200 Flavio Curti wrote: > Hello > > On Mon, Jul 09, 2007 at 11:59:36AM +1000, Nick Piggin wrote: > > >Jul 8 00:19:13 dorade.cyberlink.ch EFLAGS: 00210046 > > >(2.6.22-rc7-dorade #1) > > >>The machine panics > > >>after some days of running fine, the machine inst heavy loaded. > > >>The Controller detects as stex device: > > >kernel BUG at block/as-iosched.c:1084! > > > > > >BUG_ON(RB_EMPTY_ROOT(>sort_list[REQ_ASYNC])); > > Could be a bug in the driver that just happens to be caught by AS checks. > > If you could test another scheduler (boot with elevator=deadline or > > elevator=cfq), > > it might help give us an idea. > > Ok, I now switched to cfg, and the machine panicd again. Panic attached. > Any help is appreciated. Make sure that you switched to "cfq" and not "cfg". --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [V9fs-developer] [GIT PULL] 9p Patches for 2.6.23 merge window
I thought that it is not a good idea to keep the v9fs_ prefix for code
that is in different places (fs/9p and net/9p). If keeping the old
prefix is more acceptable, I can create a new patch without the
"v9fs_"->"p9_" renames.
Thanks,
Lucho
On 7/15/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:
On Sat, 14 Jul 2007, Eric Van Hensbergen wrote:
>
> The bulk of the changes were in the reorganization patch which mostly
> moved files and interfaces around in preparation for work on an
> in-kernel 9p server.
Please use "git diff -C --stat --summary" to generate the diffstat
summary.
In particular, because you didn't use -C (or -M), git have you an
old-style diffstat without renames, so the diffstat doesn't show that a
lot of it was moving code around.
(That said, you seem to have changed names a lot too, so it's not pure
code movement).
> 49 files changed, 5400 insertions(+), 5092 deletions(-)
With rename detection enabled, I get
36 files changed, 3444 insertions(+), 3130 deletions(-)
due to finding some (partially dubious) renames:
rename fs/9p/mux.h => include/net/9p/conn.h (53%)
rename {fs => include/net}/9p/transport.h (59%)
rename {fs => net}/9p/conv.c (55%)
rename {fs => net}/9p/fcprint.c (64%)
rename {fs => net}/9p/mux.c (55%)
even though is misses a lot of others (due to all the "v9fs" -> "p9"
changes in the source code too - was that really worth it?).
Linus
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
V9fs-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/v9fs-developer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] DRM tree for 2.6.23-rc1
On 7/16/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: On Mon, 16 Jul 2007, Dave Airlie wrote: > > Please pull the 'drm-patches' branch from the drm git tree. > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git > drm-patches This totally breaks for me. CC drivers/char/drm/drm_ioc32.o drivers/char/drm/drm_ioc32.c: In function 'compat_drm_version': drivers/char/drm/drm_ioc32.c:85: error: 'drm_version_t' undeclared (first use in this function) drivers/char/drm/drm_ioc32.c:85: error: (Each undeclared identifier is reported only once .. followed by hundreds of lines of warnings. Damn, you had to pick the week I've only got my 32-bit laptop connected to open the merge window :-), I thought it might have hit an -mm but there doesn't seem to be any during the merge window... I'll get some cross compilers down and try and squeeze them onto it.. drop it and I'll fix it up and resend... Dave. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: CONFIG_PAGE_SHIFT (aka software PAGE_SIZE)
On Fri, Jul 13, 2007 at 04:31:09PM +0200, Andrea Arcangeli wrote: > On Fri, Jul 13, 2007 at 05:13:08PM +1000, David Chinner wrote: > > Sure. Fundamentally, though, I think it is the wrong approach to > > take - it's a workaround for a big negative side effect of > > increasing page size. It introduces lots of complexity and > > difficult-to-test corner cases; judging by the tail packing problems > > reiser3 has had over the years, it has the potential to be a > > never-ending source of data corruption bugs. > > > > I think that fine granularity and aggregation for efficiency of > > scale is a better model to use than increasing the base page size. > > With PPC, you can handle different page sizes in the hardware (like > > MIPS) and the use of 64k base page size is an obvious workaround to > > the problem of not being able to use multiple page sizes within the > > OS. > > I think you're being too fs centric. Moving only the pagecache to a > large order is enough to you but it isn't enough to me, I'd like all > allocations to be faster, and I'd like to reduce the page fault > rate. Right, and that is done on other operating systems by supporting multiple hardware page sizes and telling the relevant applications to use larger pages (e.g. via cpuset configuration). > The CONFIG_PAGE_SHIFT isn't just about I/O. It's just that > CONFIG_PAGE_SHIFT will give you the I/O side for free too. It's not for free, and that's one of the points I've been trying to make. > Also keep in mind mixing multiple page sizes for different inodes has > the potential to screw the aging algorithms in the reclaim code. Just > to make an example during real random I/O over all bits of hot cache > in pagecache, a 64k page has 16 times more probability of being marked > young than a 4k page. Sure, but if a page is being hit repeatedly - regardless of it's size - then you want to keep it around > The tail packing of pagecache could very well be worth it. It should > cost nothing for the large files. As I've said before - I'm not just concerned with large files - I'm also concerned about large numbers of files (hundreds of millions to billions in a filesystem) and the scalability issues involved with them. IOWs, I'm looking at metadata scalability as much as data scalability. It's flexibility that I need from the VM, not pure VM efficiency. Shifting the base page size is not an efficient solution to the different aspects of filesystem scalability. We've got to deal with both ends of the spectrum simultaneously on the one machine in the same filesystem and it's only going to get worse in the future. Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: i386: pata_cs5520 does not work
From: Alan Cox <[EMAIL PROTECTED]> Subject: Re: i386: pata_cs5520 does not work Date: Sun, 15 Jul 2007 18:39:24 +0100 > On Mon, 16 Jul 2007 01:41:15 +0900 (JST) > TAKADA Yoshihito <[EMAIL PROTECTED]> wrote: > > > Hi. > > I update to 2.6.22.1 from 2.6.21.5. And PC cannot mount /. > > It seems pata_cs5520 does not find IDE controller. > > (I don't have serial cable for CS5520 board now. I cannt read > > boot messages.) > > 2.6.21 is OK. > > In 2.6.22, IDE driver is OK. > > Is any information necessary? > > I'll take a look at this next week. Can you send me a dmesg of the > working case and an lspci -vvxxx Thanks. attached 2 dmesgs(2.6.21 with pata_cs5520, 2.6.22 with IDE) and output of lspci. Linux version 2.6.21.5-ss2 ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #2 PREEMPT Wed Jun 27 11:01:48 JST 2007 BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009fc00 size: 0400 end: 000a type: 2 copy_e820_map() start: 000f size: 0001 end: 0010 type: 2 copy_e820_map() start: 0010 size: 05c8 end: 05d8 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: size: 0001 end: 0001 type: 2 BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 05d8 (usable) BIOS-e820: - 0001 (reserved) 93MB LOWMEM available. Entering add_active_range(0, 0, 23936) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 ->23936 early_node_map[1] active PFN ranges 0:0 ->23936 On node 0 totalpages: 23936 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 155 pages used for memmap Normal zone: 19685 pages, LIFO batch:3 DMI not present or invalid. Allocating PCI resources starting at 1000 (gap: 05d8:fa27) Built 1 zonelists. Total pages: 23749 Kernel command line: ro root=/dev/sda2 5 Initializing CPU#0 PID hash table entries: 512 (order: 9, 2048 bytes) Detected 199.746 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 90184k/95744k available (1866k kernel code, 5104k reserved, 743k data, 140k init, 0k highmem) virtual kernel memory layout: fixmap : 0xd000 - 0xf000 ( 8 kB) vmalloc : 0xc680 - 0xb000 ( 919 MB) lowmem : 0xc000 - 0xc5d8 ( 93 MB) .init : 0xc039 - 0xc03b3000 ( 140 kB) .data : 0xc02d2afd - 0xc038c934 ( 743 kB) .text : 0xc010 - 0xc02d2afd (1866 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 403.39 BogoMIPS (lpj=672636) Mount-cache hash table entries: 512 CPU: After generic identify, caps: 00808131 01818131 CPU: After vendor identify, caps: 00808131 01818131 Working around Cyrix MediaGX virtual DMA bugs. Enable Memory-Write-back mode on Cyrix/NSC processor. Enable Memory access reorder on Cyrix/NSC processor. Enable Incrementor on Cyrix/NSC processor. CPU: After all inits, caps: 00808131 00818131 0001 CPU: Cyrix MediaGXtm MMXtm Enhanced stepping 02 Checking 'hlt' instruction... OK. Device driver platform lacks bus and class support for being resumed. NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0 PCI: Using configuration type 1 Setting up standard PCI resources SCSI subsystem initialized libata version 2.20 loaded. usbcore: registered new interface driver usbfs USB driver usbfs lacks resume support. usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Device driver pci:00 lacks bus and class support for being resumed. PCI: Using IRQ router default [1078/0001] at :00:00.0 Time: tsc clocksource has been installed. PCI: Bus 1, cardbus bridge: :00:01.0 IO window: 1000-10ff IO window: 1400-14ff PREFETCH window: 1000-13ff MEM window: 1400-17ff PCI: Setting latency timer of device :00:01.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes) TCP: Hash tables configured (established 4096 bind 4096) TCP
Re: [git pull] DRM tree for 2.6.23-rc1
On Mon, 16 Jul 2007, Dave Airlie wrote: > > Please pull the 'drm-patches' branch from the drm git tree. > ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git > drm-patches This totally breaks for me. CC drivers/char/drm/drm_ioc32.o drivers/char/drm/drm_ioc32.c: In function ‘compat_drm_version’: drivers/char/drm/drm_ioc32.c:85: error: ‘drm_version_t’ undeclared (first use in this function) drivers/char/drm/drm_ioc32.c:85: error: (Each undeclared identifier is reported only once .. followed by hundreds of lines of warnings. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Sun, 15 Jul 2007, Alan Stern wrote: On Sun, 15 Jul 2007, Al Boldi wrote: Alan Stern wrote: On Sun, 15 Jul 2007, Al Boldi wrote: This should be the responsibility of the kexec'd hibernating kernel. Note though in (6), the normal kernel takes care of preparing devices, then the hibernating kernel dumps the image and either calls S4 or S3. On resume from S3 it can immediately switch over to the normal kernel, and from S4 the known bootup would occur. Is it really that simple? Somehow I doubt it. In order for some devices to remain available for the kexec'd kernel to use, they cannot be suspended at the ACPI level. So the kexec'd kernel will have to handle the ACPI requirements for those devices. Likewise, it would have to handle the ACPI interactions which need to be done after all devices are prepared for the transition to S3 or S4. Ok, after applying the latest kexec patches, I was able to use the kexec'd kernel to suspend to ram and resume to the normal kernel, while working under a full-blown X session. It went without a hitch. All that is needed now are the dump/restore hibernation-image routines. That's exactly my point. While doing suspend-to-RAM from a kexec'd kernel may be simple, saving the hibernation image will add complications. suspend-to-RAM should not involve kexec, the only reason for doing the kexec to to get a seperate userspace to use for suspend-to-disk operations instead of trying to partially freeze the sustem and keep useing it. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] DRM tree for 2.6.23-rc1
Hi Linus, Please pull the 'drm-patches' branch from the drm git tree. ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-patches It contains a removal of a lot of typedefs from the core drm and their use in drivers. Drivers will have their own typedefs cleaned later. It also contains an updated r300 register file, and radeon vblank routing support along with a list macro cleanup. Dave. drivers/char/drm/ati_pcigart.c|8 +- drivers/char/drm/drm.h| 329 ++- drivers/char/drm/drmP.h | 349 ++-- drivers/char/drm/drm_agpsupport.c | 116 ++-- drivers/char/drm/drm_auth.c | 40 +- drivers/char/drm/drm_bufs.c | 209 drivers/char/drm/drm_context.c| 97 ++-- drivers/char/drm/drm_dma.c| 12 +- drivers/char/drm/drm_drawable.c | 34 +- drivers/char/drm/drm_drv.c| 76 ++-- drivers/char/drm/drm_fops.c | 68 +-- drivers/char/drm/drm_hashtab.c| 34 +- drivers/char/drm/drm_hashtab.h| 24 +- drivers/char/drm/drm_ioctl.c | 68 ++- drivers/char/drm/drm_irq.c| 58 +- drivers/char/drm/drm_lock.c | 28 +- drivers/char/drm/drm_memory.c |8 +- drivers/char/drm/drm_mm.c | 66 +- drivers/char/drm/drm_os_linux.h | 22 +- drivers/char/drm/drm_pci.c|6 +- drivers/char/drm/drm_proc.c | 50 +- drivers/char/drm/drm_sarea.h | 26 +- drivers/char/drm/drm_scatter.c| 22 +- drivers/char/drm/drm_sman.c | 93 ++-- drivers/char/drm/drm_sman.h | 50 +- drivers/char/drm/drm_stub.c | 30 +- drivers/char/drm/drm_sysfs.c |4 +- drivers/char/drm/drm_vm.c | 106 ++-- drivers/char/drm/i810_dma.c | 164 +++--- drivers/char/drm/i810_drm.h |2 +- drivers/char/drm/i810_drv.h | 18 +- drivers/char/drm/i830_dma.c | 157 +++--- drivers/char/drm/i830_drm.h |2 +- drivers/char/drm/i830_drv.h | 24 +- drivers/char/drm/i830_irq.c | 20 +- drivers/char/drm/i915_dma.c | 44 +- drivers/char/drm/i915_drm.h |8 +- drivers/char/drm/i915_drv.h | 22 +- drivers/char/drm/i915_irq.c | 28 +- drivers/char/drm/i915_mem.c |6 +- drivers/char/drm/mga_dma.c| 79 ++-- drivers/char/drm/mga_drm.h|6 +- drivers/char/drm/mga_drv.c|4 +- drivers/char/drm/mga_drv.h| 22 +- drivers/char/drm/mga_irq.c| 12 +- drivers/char/drm/mga_state.c | 36 +- drivers/char/drm/r128_cce.c | 41 +- drivers/char/drm/r128_drm.h |4 +- drivers/char/drm/r128_drv.h | 20 +- drivers/char/drm/r128_irq.c | 10 +- drivers/char/drm/r128_state.c | 60 +- drivers/char/drm/r300_cmdbuf.c| 53 +- drivers/char/drm/r300_reg.h | 1163 + drivers/char/drm/radeon_cp.c | 54 +- drivers/char/drm/radeon_drm.h | 12 +- drivers/char/drm/radeon_drv.c |3 +- drivers/char/drm/radeon_drv.h | 45 +- drivers/char/drm/radeon_irq.c | 118 - drivers/char/drm/radeon_state.c | 108 ++-- drivers/char/drm/savage_bci.c | 44 +- drivers/char/drm/savage_drm.h |4 +- drivers/char/drm/savage_drv.h | 20 +- drivers/char/drm/savage_state.c | 28 +- drivers/char/drm/sis_drv.c|4 +- drivers/char/drm/sis_drv.h|9 +- drivers/char/drm/sis_mm.c | 16 +- drivers/char/drm/via_dma.c| 10 +- drivers/char/drm/via_dmablit.c| 20 +- drivers/char/drm/via_dmablit.h|2 +- drivers/char/drm/via_drm.h|4 +- drivers/char/drm/via_drv.h| 32 +- drivers/char/drm/via_irq.c| 12 +- drivers/char/drm/via_map.c| 10 +- drivers/char/drm/via_mm.c |6 +- drivers/char/drm/via_verifier.c | 12 +- drivers/char/drm/via_verifier.h |6 +- 76 files changed, 2444 insertions(+), 2173 deletions(-) commit bd63cb52c05bbb154f539369cae4fb9c9b6277da Author: Dave Airlie <[EMAIL PROTECTED]> Date: Thu Jul 12 10:35:02 2007 +1000 drm: remove sarea typedefs Leave the userspace typedefs in place Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit e0be428e6645f2891fab6be92d1b0e9aad972e7d Author: Dave Airlie <[EMAIL PROTECTED]> Date: Thu Jul 12 10:26:44 2007 +1000 drm: detypedef the hashtab and more of sman Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit 9698b4dba42eb758ad98012c21e5fbdb372fe2d9 Author: Dave Airlie <[EMAIL PROTECTED]> Date: Thu Jul 12 10:21:05 2007 +1000 drm: de-typedef sman Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit 55910517af381eba4f978740e5e46e23eb269326 Author: Dave Airlie <[EMAIL PROTECTED]> Date: Wed Jul 11 16:53:40 2007 +1000 drm: detypedeffing continues... Signed-off-by: Dave Airlie <[EMAIL PROTECTED]> commit cdd55a294c13f8bf05b2f4fee4c96934d5ebd2e4 Author: Dave Airlie <[EMAIL PROTECTED]> Date: Wed Jul 11
Re: Hibernation considerations
On Sun, 15 Jul 2007, Alan Stern wrote: On Sun, 15 Jul 2007 [EMAIL PROTECTED] wrote: (1) Filesystems mounted before the hibernation are untouchable When there's a memory snapshot, either in the form of a hibernation image, or in the form of the "old" kernel and processes available to the "new" kexeced kernel responsible for saving their memory, the filesystems mounted before the hibernation should not be accessed, even for reading, because that would cause their on-disk state to be inconsistent with the snapshot and might lead to a filesystem corruption. AFAIK this is only the case with ext3, all other filesystems could be accessed read-only safely this is arguably a bug with ext3 (and has been discussed as such), but right now the ext3 team has decided not to change this bahavior so hibernate needs to work around it. but don't mistake a work-around for a single (admittedly very popular) filesystem with a hard and fast directive. Isn't is possible to avoid this problem by mounting an ext3 filesystem as readonly ext2? Provided the filesystem isn't dirty it should be doable. (And provided the filesystem doesn't use any ext3 extensions that are incompatible with ext2.) from the last discussion I saw on the kernel mailing list, no. the act of mounting the ext3 filesystem as ext2 read-only will change it as the unsupported extentions get turned off (and I think the journal contents at least are lost as part of this) David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] i386: Geode's TSC is not neccessary to mark tu unstable
Hi. Thanks. you are right. TSC is still unstable. On Sun, 15 Jul 2007 21:06:27 +0200 Juergen Beisert <[EMAIL PROTECTED]> wrote: > Hi, > > On Sunday 15 July 2007 14:00, TAKADA Yoshihito wrote: > > Hi. I reported to remove pit_latch_buggy(http://lkml.org/lkml/2007/2/10/8). > > In the report, I stated that TSC was unstable. > > When I installed 2.6.21, GeodeGX's TSC is stable. > > GeodeGX1's TSC is stable until you activate halt/suspend feature. In > arch/i386/kernel/cpu/cyrix.c:geode_configure() it will be activated by > default. But due to a macro failure the line > setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88); > does nothing. > Replace the setCx86/getCx86 macros by the attached patch, and the TSC will be > unstable again! > > So it makes sense to mark the TSC unstable if the halt/suspend feature is > activated. > > Juergen -- TAKADA <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote: On Monday, 16 July 2007 00:42, [EMAIL PROTECTED] wrote: On Mon, 16 Jul 2007, Rafael J. Wysocki wrote: On Sunday, 15 July 2007 22:13, [EMAIL PROTECTED] wrote: On Sun, 15 Jul 2007, Rafael J. Wysocki wrote: The ACPI specification requires us to invoke some global ACPI methods during the hibernation and during the restore. Moreover, the ordering of code related to these ACPI methods may not be arbitrary (eg. some of them have to be executed after devices are put into low power states etc.). for a pure hibernate mode, you will be powering off the box after saving the suspend image. why are there any special ACPI modes involved? Because, for example, on my machine the status of power supply (present vs not present) is not updated correctly after the restore if ACPI callbacks aren't used during the hibernation. That's just experience and it's in line with the ACPI spec. so if a machine is actually powered off the /dev/suspend process won't work? No, it sort of works as usual, but after the restore the platform is not in the correct state. this is not hibernate as I and many others are thinking of it. hibernate as we are thinking would work on basicly any hardware, including things with no ACPI or power savings support. and the system could be in hibernate mode for any time period. for that matter, after a system is put into hibernate mode the system could be completely disassembled and any components replaced and the system would work after a resume (assuming you still have access to the suspend image) remember that the system may run a different OS between the hibernate and the resume, makeing any assumptions about what state the hardware is in when you start the resume is a problem. True, that's problematic. putting it mildly. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] 9p Patches for 2.6.23 merge window
On Sat, 14 Jul 2007, Eric Van Hensbergen wrote:
>
> The bulk of the changes were in the reorganization patch which mostly
> moved files and interfaces around in preparation for work on an
> in-kernel 9p server.
Please use "git diff -C --stat --summary" to generate the diffstat
summary.
In particular, because you didn't use -C (or -M), git have you an
old-style diffstat without renames, so the diffstat doesn't show that a
lot of it was moving code around.
(That said, you seem to have changed names a lot too, so it's not pure
code movement).
> 49 files changed, 5400 insertions(+), 5092 deletions(-)
With rename detection enabled, I get
36 files changed, 3444 insertions(+), 3130 deletions(-)
due to finding some (partially dubious) renames:
rename fs/9p/mux.h => include/net/9p/conn.h (53%)
rename {fs => include/net}/9p/transport.h (59%)
rename {fs => net}/9p/conv.c (55%)
rename {fs => net}/9p/fcprint.c (64%)
rename {fs => net}/9p/mux.c (55%)
even though is misses a lot of others (due to all the "v9fs" -> "p9"
changes in the source code too - was that really worth it?).
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Linux Kernel Markers - Architecture Independent Code - kerneldoc for implementation
Linux Kernel Markers - Architecture Independent Code - kerneldoc for
implementation
Add kerneldoc to Linux Kernel Markers API.
It applies after
"linux-kernel-markers-architecture-independent-code-remove-ifdef-kernel.patch"
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
include/linux/marker.h | 37 +---
kernel/marker.c| 113 ++---
2 files changed, 112 insertions(+), 38 deletions(-)
Index: linux-2.6-lttng/include/linux/marker.h
===
--- linux-2.6-lttng.orig/include/linux/marker.h 2007-07-15 19:19:10.0
-0400
+++ linux-2.6-lttng/include/linux/marker.h 2007-07-15 19:20:47.0
-0400
@@ -18,6 +18,15 @@
struct module;
struct __mark_marker;
+/**
+ * marker_probe_func - Type of a marker probe function
+ * @mdata: pointer of type struct __mark_marker
+ * @fmt: format string
+ * @...: variable argument list
+ *
+ * Type of marker probe functions. They receive the mdata and need to parse the
+ * format string to recover the variable argument list.
+ */
typedef void marker_probe_func(const struct __mark_marker *mdata,
const char *fmt, ...);
@@ -86,18 +95,36 @@ extern void module_marker_update(struct
static inline void module_marker_update(struct module *mod) { }
#endif /* CONFIG_MARKERS */
-/* Marker with default behavior */
+/**
+ * trace_mark - Marker using code patching
+ * @name: marker name, not quoted.
+ * @format: format string
+ * @args...: variable argument list
+ *
+ * Places a marker using optimized code patching technique (immediate_if ())
+ * to be enabled.
+ */
#define trace_mark(name, format, args...) \
__trace_mark(0, name, format, ## args)
-/*
- * Map to the generic marker. Should be used for markers in __init and __exit
- * functions and in lockdep code.
+
+/**
+ * _trace_mark - Marker using variable read
+ * @name: marker name, not quoted.
+ * @format: format string
+ * @args...: variable argument list
+ *
+ * Places a marker using a standard memory read (_immediate_if ()) to be
+ * enabled. Should be used for markers in __init and __exit functions and in
+ * lockdep code.
*/
#define _trace_mark(name, format, args...) \
__trace_mark(1, name, format, ## args)
#define MARK_MAX_FORMAT_LEN1024
-/* Pass this as a format string for a marker with no argument */
+
+/**
+ * MARK_NOARGS - Format string for a marker with no argument.
+ */
#define MARK_NOARGS " "
/* To be used for string format validity checking with gcc */
Index: linux-2.6-lttng/kernel/marker.c
===
--- linux-2.6-lttng.orig/kernel/marker.c2007-07-15 19:20:53.0
-0400
+++ linux-2.6-lttng/kernel/marker.c 2007-07-15 19:26:53.0 -0400
@@ -62,7 +62,12 @@ struct marker_entry {
static struct hlist_head marker_table[MARKER_TABLE_SIZE];
-/*
+/**
+ * __mark_empty_function - Empty probe callback
+ * @mdata: pointer of type const struct __mark_marker
+ * @fmt: format string
+ * @...: variable argument list
+ *
* Empty callback provided as a probe to the markers. By providing this to a
* disabled marker, we makes sure the execution flow is always valid even
* though the function pointer change and the marker enabling are two distinct
@@ -199,7 +204,9 @@ static int _marker_set_format(struct mar
return 0;
}
-/* Sets the probe callback corresponding to one marker. */
+/*
+ * Sets the probe callback corresponding to one marker.
+ */
static int _set_marker(struct marker_entry **entry,
struct __mark_marker *elem)
{
@@ -320,11 +327,13 @@ static inline void __marker_update_probe
}
#ifdef CONFIG_MODULES
-/*
+/**
+ * module_marker_update - Update module's markers
+ * @mod: pointer of type struct module identifying the target module
+ *
* Setup the marker according to the data present in the marker hash table
- * upon module load. If an error occur during the set probe range,
- * refuse to load the module. Must be called with module_mutex held.
- * Since the probe_module parameter is NULL, it is safe for refcount to be
NULL.
+ * upon module load. Must be called with module_mutex held. Since the
+ * probe_module parameter is NULL, it is safe for refcount to be NULL.
*/
void module_marker_update(struct module *mod)
{
@@ -334,7 +343,8 @@ void module_marker_update(struct module
}
/*
- * Update the system wide probes, with modules. */
+ * Update the system wide probes, with modules.
+ */
static inline void _marker_update_probes(struct module *probe_module)
{
mutex_lock(_mutex);
@@ -342,16 +352,24 @@ static inline void _marker_update_probes
mutex_unlock(_mutex);
}
#else
-/* Update the system wide probes, without modules. */
+/*
+ * Update the system wide probes, without modules.
+ */
static inline void _marker_update_probes(struct module *probe_module)
{
Re: [PATCH] Linux Kernel Markers - Architecture Independent Code - kerneldoc for implementation
Please drop: it came from the wrong email. I will resend.
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> Linux Kernel Markers - Architecture Independent Code - kerneldoc for
> implementation
>
> Add kerneldoc to Linux Kernel Markers API.
> It applies after:
> "linux-kernel-markers-architecture-independent-code-remove-ifdef-kernel.patch"
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> ---
> include/linux/marker.h | 37 +---
> kernel/marker.c| 113
> ++---
> 2 files changed, 112 insertions(+), 38 deletions(-)
>
> Index: linux-2.6-lttng/include/linux/marker.h
> ===
> --- linux-2.6-lttng.orig/include/linux/marker.h 2007-07-15
> 19:19:10.0 -0400
> +++ linux-2.6-lttng/include/linux/marker.h2007-07-15 19:20:47.0
> -0400
> @@ -18,6 +18,15 @@
> struct module;
> struct __mark_marker;
>
> +/**
> + * marker_probe_func - Type of a marker probe function
> + * @mdata: pointer of type struct __mark_marker
> + * @fmt: format string
> + * @...: variable argument list
> + *
> + * Type of marker probe functions. They receive the mdata and need to parse
> the
> + * format string to recover the variable argument list.
> + */
> typedef void marker_probe_func(const struct __mark_marker *mdata,
> const char *fmt, ...);
>
> @@ -86,18 +95,36 @@ extern void module_marker_update(struct
> static inline void module_marker_update(struct module *mod) { }
> #endif /* CONFIG_MARKERS */
>
> -/* Marker with default behavior */
> +/**
> + * trace_mark - Marker using code patching
> + * @name: marker name, not quoted.
> + * @format: format string
> + * @args...: variable argument list
> + *
> + * Places a marker using optimized code patching technique (immediate_if ())
> + * to be enabled.
> + */
> #define trace_mark(name, format, args...) \
> __trace_mark(0, name, format, ## args)
> -/*
> - * Map to the generic marker. Should be used for markers in __init and __exit
> - * functions and in lockdep code.
> +
> +/**
> + * _trace_mark - Marker using variable read
> + * @name: marker name, not quoted.
> + * @format: format string
> + * @args...: variable argument list
> + *
> + * Places a marker using a standard memory read (_immediate_if ()) to be
> + * enabled. Should be used for markers in __init and __exit functions and in
> + * lockdep code.
> */
> #define _trace_mark(name, format, args...) \
> __trace_mark(1, name, format, ## args)
>
> #define MARK_MAX_FORMAT_LEN 1024
> -/* Pass this as a format string for a marker with no argument */
> +
> +/**
> + * MARK_NOARGS - Format string for a marker with no argument.
> + */
> #define MARK_NOARGS " "
>
> /* To be used for string format validity checking with gcc */
> Index: linux-2.6-lttng/kernel/marker.c
> ===
> --- linux-2.6-lttng.orig/kernel/marker.c 2007-07-15 19:20:53.0
> -0400
> +++ linux-2.6-lttng/kernel/marker.c 2007-07-15 19:26:53.0 -0400
> @@ -62,7 +62,12 @@ struct marker_entry {
>
> static struct hlist_head marker_table[MARKER_TABLE_SIZE];
>
> -/*
> +/**
> + * __mark_empty_function - Empty probe callback
> + * @mdata: pointer of type const struct __mark_marker
> + * @fmt: format string
> + * @...: variable argument list
> + *
> * Empty callback provided as a probe to the markers. By providing this to a
> * disabled marker, we makes sure the execution flow is always valid even
> * though the function pointer change and the marker enabling are two
> distinct
> @@ -199,7 +204,9 @@ static int _marker_set_format(struct mar
> return 0;
> }
>
> -/* Sets the probe callback corresponding to one marker. */
> +/*
> + * Sets the probe callback corresponding to one marker.
> + */
> static int _set_marker(struct marker_entry **entry,
> struct __mark_marker *elem)
> {
> @@ -320,11 +327,13 @@ static inline void __marker_update_probe
> }
>
> #ifdef CONFIG_MODULES
> -/*
> +/**
> + * module_marker_update - Update module's markers
> + * @mod: pointer of type struct module identifying the target module
> + *
> * Setup the marker according to the data present in the marker hash table
> - * upon module load. If an error occur during the set probe range,
> - * refuse to load the module. Must be called with module_mutex held.
> - * Since the probe_module parameter is NULL, it is safe for refcount to be
> NULL.
> + * upon module load. Must be called with module_mutex held. Since the
> + * probe_module parameter is NULL, it is safe for refcount to be NULL.
> */
> void module_marker_update(struct module *mod)
> {
> @@ -334,7 +343,8 @@ void module_marker_update(struct module
> }
>
> /*
> - * Update the system wide probes, with modules. */
> + * Update the system wide probes, with modules.
> + */
> static inline void
Re: Hibernation considerations
On Sun, 15 Jul 2007, Alan Stern wrote: On Sun, 15 Jul 2007 [EMAIL PROTECTED] wrote: for a pure hibernate mode, you will be powering off the box after saving the suspend image. why are there any special ACPI modes involved? Because, for example, on my machine the status of power supply (present vs not present) is not updated correctly after the restore if ACPI callbacks aren't used during the hibernation. That's just experience and it's in line with the ACPI spec. so if a machine is actually powered off the /dev/suspend process won't work? remember that the system may run a different OS between the hibernate and the resume, makeing any assumptions about what state the hardware is in when you start the resume is a problem. As I understand it, running a different OS between the hibernate and the resume would violate the ACPI spec. then we need a third mode of operation. mode 1: Suspend-to-ram the system is paused and put into a low-power mode but data remains in memory and the system stays awake enough to keep the memory refreshed. mode 2: new the system is paused, data is stored to permanent media, and the system is put into a ultra-low power mode. mode 3: hibernate the system is paused, data is stored to permanent media, and the system is powered off with mode 3 there are no requirements or limitations about what can be done with the hardware before a resume (the resume could even take place on a different piece of identical hardware) mode 2 could be what you are talking about doing, although I don't see any advantage of creating it in additon to mode 3, it doesn't use any less power and it locks the system so that it can't be used for anything else in the meantime. I guess if it was significantly faster to do then mode 3 there may be _some_ reason to consider it, but I don't see the speed difference. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Linux Kernel Markers - Architecture Independent Code - kerneldoc for implementation
Linux Kernel Markers - Architecture Independent Code - kerneldoc for
implementation
Add kerneldoc to Linux Kernel Markers API.
It applies after:
"linux-kernel-markers-architecture-independent-code-remove-ifdef-kernel.patch"
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
include/linux/marker.h | 37 +---
kernel/marker.c| 113 ++---
2 files changed, 112 insertions(+), 38 deletions(-)
Index: linux-2.6-lttng/include/linux/marker.h
===
--- linux-2.6-lttng.orig/include/linux/marker.h 2007-07-15 19:19:10.0
-0400
+++ linux-2.6-lttng/include/linux/marker.h 2007-07-15 19:20:47.0
-0400
@@ -18,6 +18,15 @@
struct module;
struct __mark_marker;
+/**
+ * marker_probe_func - Type of a marker probe function
+ * @mdata: pointer of type struct __mark_marker
+ * @fmt: format string
+ * @...: variable argument list
+ *
+ * Type of marker probe functions. They receive the mdata and need to parse the
+ * format string to recover the variable argument list.
+ */
typedef void marker_probe_func(const struct __mark_marker *mdata,
const char *fmt, ...);
@@ -86,18 +95,36 @@ extern void module_marker_update(struct
static inline void module_marker_update(struct module *mod) { }
#endif /* CONFIG_MARKERS */
-/* Marker with default behavior */
+/**
+ * trace_mark - Marker using code patching
+ * @name: marker name, not quoted.
+ * @format: format string
+ * @args...: variable argument list
+ *
+ * Places a marker using optimized code patching technique (immediate_if ())
+ * to be enabled.
+ */
#define trace_mark(name, format, args...) \
__trace_mark(0, name, format, ## args)
-/*
- * Map to the generic marker. Should be used for markers in __init and __exit
- * functions and in lockdep code.
+
+/**
+ * _trace_mark - Marker using variable read
+ * @name: marker name, not quoted.
+ * @format: format string
+ * @args...: variable argument list
+ *
+ * Places a marker using a standard memory read (_immediate_if ()) to be
+ * enabled. Should be used for markers in __init and __exit functions and in
+ * lockdep code.
*/
#define _trace_mark(name, format, args...) \
__trace_mark(1, name, format, ## args)
#define MARK_MAX_FORMAT_LEN1024
-/* Pass this as a format string for a marker with no argument */
+
+/**
+ * MARK_NOARGS - Format string for a marker with no argument.
+ */
#define MARK_NOARGS " "
/* To be used for string format validity checking with gcc */
Index: linux-2.6-lttng/kernel/marker.c
===
--- linux-2.6-lttng.orig/kernel/marker.c2007-07-15 19:20:53.0
-0400
+++ linux-2.6-lttng/kernel/marker.c 2007-07-15 19:26:53.0 -0400
@@ -62,7 +62,12 @@ struct marker_entry {
static struct hlist_head marker_table[MARKER_TABLE_SIZE];
-/*
+/**
+ * __mark_empty_function - Empty probe callback
+ * @mdata: pointer of type const struct __mark_marker
+ * @fmt: format string
+ * @...: variable argument list
+ *
* Empty callback provided as a probe to the markers. By providing this to a
* disabled marker, we makes sure the execution flow is always valid even
* though the function pointer change and the marker enabling are two distinct
@@ -199,7 +204,9 @@ static int _marker_set_format(struct mar
return 0;
}
-/* Sets the probe callback corresponding to one marker. */
+/*
+ * Sets the probe callback corresponding to one marker.
+ */
static int _set_marker(struct marker_entry **entry,
struct __mark_marker *elem)
{
@@ -320,11 +327,13 @@ static inline void __marker_update_probe
}
#ifdef CONFIG_MODULES
-/*
+/**
+ * module_marker_update - Update module's markers
+ * @mod: pointer of type struct module identifying the target module
+ *
* Setup the marker according to the data present in the marker hash table
- * upon module load. If an error occur during the set probe range,
- * refuse to load the module. Must be called with module_mutex held.
- * Since the probe_module parameter is NULL, it is safe for refcount to be
NULL.
+ * upon module load. Must be called with module_mutex held. Since the
+ * probe_module parameter is NULL, it is safe for refcount to be NULL.
*/
void module_marker_update(struct module *mod)
{
@@ -334,7 +343,8 @@ void module_marker_update(struct module
}
/*
- * Update the system wide probes, with modules. */
+ * Update the system wide probes, with modules.
+ */
static inline void _marker_update_probes(struct module *probe_module)
{
mutex_lock(_mutex);
@@ -342,16 +352,24 @@ static inline void _marker_update_probes
mutex_unlock(_mutex);
}
#else
-/* Update the system wide probes, without modules. */
+/*
+ * Update the system wide probes, without modules.
+ */
static inline void _marker_update_probes(struct module *probe_module)
{
Re: Re: [ANNOUNCE][RFC] PlugSched-6.5.1 for 2.6.22
On Sun, Jul 15, 2007 at 10:47:51AM -0700, Li, Tong N wrote: > > On Thursday 12 July 2007 00:17, Al Boldi wrote: > > > > > Peter Williams wrote: > > >> > > >> Probably the last one now that CFS is in the main line :-(. > > > > > > What do you mean? A pluggable scheduler framework is indispensible > even > > in > > > the presence of CFS or SD. > > > > Indeed, and I hope it gets merged, giving people the chance to test > out > > different schedulers easily, without having to do patching, > de-patching, > > re-patching and blah blah blah. > > > > Yes, such a framework would be invaluable, especially given that > scheduling often has conflicting goals and different workloads have > different requirements. No single solution fits all. >... Having a framework for giving people the choice between different solutions usually sounds good in theory, but in practice there's the often underestimated high price of people using a different solution instead of reporting a problem with one solution or people adding features to only one of the solutions resulting in different solutions having different features and bugs instead of one solution with all features and bug fixes. So you should give a good technical explanation why it's not technically possible or not desirable for one solution to work well for everyone. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Linux Kernel Markers - Architecture Independent Code Remove ifdef KERNEL
Linux Kernel Markers - Architecture Independent Code Remove ifdef kernel Remove #ifdef __KERNEL__ in marker.h. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] --- include/linux/marker.h |3 --- 1 file changed, 3 deletions(-) Index: linux-2.6-lttng/include/linux/marker.h === --- linux-2.6-lttng.orig/include/linux/marker.h 2007-07-15 19:17:05.0 -0400 +++ linux-2.6-lttng/include/linux/marker.h 2007-07-15 19:17:28.0 -0400 @@ -12,8 +12,6 @@ * See the file COPYING for more details. */ -#ifdef __KERNEL__ - #include #include @@ -132,5 +130,4 @@ extern struct __mark_marker *marker_get_ extern void marker_release(struct __mark_marker *iter); extern void *marker_get_pdata(const char *name); -#endif /* __KERNEL__ */ #endif -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL][RESEND] KVM Updates for 2.6.23-rc1
On Sat, 14 Jul 2007, Avi Kivity wrote: > > Linus, please do your usual thing from the repository and branch at It has code like + /* Can deadlock when called with interrupts disabled */ + WARN_ON(irqs_disabled()); + /* prevent preemption and reschedule on another processor */ int me = get_cpu(); which is against the coding conventions (and shouldn't even compile cleanly - but maybe we don't have the "warn about C99 variable declarations" thng on?). Please don't do that. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Immediate Values - PowerPC Optimization - kerneldoc for implementation
Immediate Values - PowerPC Optimization - kerneldoc for implementation
Add kerneldoc to Immediate Values (PowerPC Optimization) API.
It applies after
"Immediate Values - PowerPC Optimization - kerneldoc"
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
arch/powerpc/kernel/immediate.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
Index: linux-2.6-lttng/arch/powerpc/kernel/immediate.c
===
--- linux-2.6-lttng.orig/arch/powerpc/kernel/immediate.c2007-07-15
19:10:32.0 -0400
+++ linux-2.6-lttng/arch/powerpc/kernel/immediate.c 2007-07-15
19:11:50.0 -0400
@@ -13,8 +13,11 @@
#define LI_OPCODE_LEN 2
-/*
- * The immediate value are aligned.
+/**
+ * arch_immediate_update - update one immediate value
+ * @immediate: pointer of type const struct __immediate to update
+ *
+ * Update one immediate value. Must be called with immediate_mutex held.
*/
int arch_immediate_update(const struct __immediate *immediate)
{
@@ -68,8 +71,11 @@ int arch_immediate_update(const struct _
return 0;
}
-/*
- * Very early initialization of the in-core immediate values.
+/**
+ * arch_immediate_update_early - update one immediate value at boot time
+ * @immediate: pointer of type const struct __immediate to update
+ *
+ * Update one immediate value at boot time.
* We can use flush_icache_range, since the cpu identification has been done in
* the early_init stage.
*/
@@ -95,4 +101,3 @@ void __init arch_immediate_update_early(
flush_icache_range((unsigned long)immediate->immediate,
immediate->size);
}
-
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Immediate Values - i386 Optimization - kerneldoc for implementation
Immediate Values - i386 Optimization - kerneldoc for implementation
Add kerneldoc to Immediate Values (i386 Optimization) API.
It applies after
"Immediate Values - i386 Optimization - kerneldoc"
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
arch/i386/kernel/immediate.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
Index: linux-2.6-lttng/arch/i386/kernel/immediate.c
===
--- linux-2.6-lttng.orig/arch/i386/kernel/immediate.c 2007-07-15
19:08:03.0 -0400
+++ linux-2.6-lttng/arch/i386/kernel/immediate.c2007-07-15
19:09:56.0 -0400
@@ -170,8 +170,12 @@ static struct notifier_block immediate_n
.priority = 0x7fff, /* we need to be notified first */
};
-/*
- * Must be called with immediate_mutex held.
+
+/**
+ * arch_immediate_update - update one immediate value
+ * @immediate: pointer of type const struct __immediate to update
+ *
+ * Update one immediate value. Must be called with immediate_mutex held.
*/
__kprobes int arch_immediate_update(const struct __immediate *immediate)
{
@@ -266,8 +270,11 @@ __kprobes int arch_immediate_update(cons
return 0;
}
-/*
- * Very early initialization of the in-core immediate values.
+/**
+ * arch_immediate_update_early - update one immediate value at boot time
+ * @immediate: pointer of type const struct __immediate to update
+ *
+ * Update one immediate value at boot time.
*/
void __init arch_immediate_update_early(const struct __immediate *immediate)
{
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote: On Sunday, 15 July 2007 21:33, [EMAIL PROTECTED] wrote: On Sun, 15 Jul 2007, Rafael J. Wysocki wrote: On Saturday, 14 July 2007 23:34, [EMAIL PROTECTED] wrote: On Sat, 14 Jul 2007, Rafael J. Wysocki wrote: On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote: On Fri, 13 Jul 2007, Rafael J. Wysocki wrote: since people are complaining about the amount of ram that a kexec kernel would take up I'm assuiming it's somethingmore complex then just a bitmap of all possible pages. No, it's just bitmaps, AFAICS, and the complaints are a bit overstated, IMO. ;-) 1 bit for each 4k means 1m bits for 4g of ram, or 128k of bitmaps, growing up to 1m of ram used for 32G of ram in the system. I guess this isn't bad as long as it doesn't need to be contiguous for the new kernel to access it. ok, that makes it a pretty trivial thing to work with. I just need to learn how to find the bitmaps. They are created on the fly before the hibernation. The format is described in kernel/power/snapshot.c . I'll look through this file, but the format of this is an abi/api to the userspace and should be documented outside of the code. Nope. The user space need not know anything about the image contents. The current implementation of the user space tools use the knowledge of the image header format, which is given by 'struct swsusp_info', defined in kernel/power/power.h . there are a couple factors here. 1. this needs to remain the same across different kernel versions. Not exactly. Whatever is after the image header may change at any time and the user space should not rely on that not changing. The header itself is a (slightly) different matter. ok, more precisely an image of one kernel version should be able to be fed into /dev/snapshot of another kernel version and work. that's what I was meaning about it needing to be the same across different kernel versions 2. this may or may not be created by userspace tools Well, the image header is not created by userspace tools and only read the image size from it. it's not today, but maby it should be. in the kexec approach there's nothing happening here that a perl script couldn't do perfectly well. it's reading a bitmap from somewhere, and based on that bitmap it creates a header and then reads chunks from /dev/oldmem or /dev/mem and writes the results somewhere (to a device, or a network or a userspace compress program, or ...) both of these tend to imply that this is an interface to the world and needs to be documented and stable. Well, it should be documented, but currently there's only one implementation of the userland tools and the authors of these know the format. ;-) true today, but as the pieces get simplified and documented other implementations could exist. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Immediate Values - Architecture Independent Code - kerneldoc for implementation
Immediate Values - Architecture Independent Code - kerneldoc for implementation
Add kerneldoc to Immediate Values API.
It applies after
"Immediate Values - Architecture Independent Code - kerneldoc"
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
kernel/immediate.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
Index: linux-2.6-lttng/kernel/immediate.c
===
--- linux-2.6-lttng.orig/kernel/immediate.c 2007-07-15 19:04:08.0
-0400
+++ linux-2.6-lttng/kernel/immediate.c 2007-07-15 19:07:14.0 -0400
@@ -54,7 +54,10 @@ static inline void _immediate_update_ran
}
#ifdef CONFIG_MODULES
-/*
+/**
+ * module_immediate_setup - Update immediate values in a module
+ * @mod: pointer to the struct module
+ *
* Setup the immediate according to the variable upon which it depends. Called
* by load_module with module_mutex held. This mutex protects against
concurrent
* modifications to modules'immediates. Therefore, since
@@ -89,6 +92,12 @@ static inline void immediate_update_modu
static inline void immediate_update_modules(int lock) { }
#endif
+/**
+ * immediate_update - update all immediate values in the kernel
+ * @lock: should a module_mutex be taken ?
+ *
+ * Iterate on the kernel core and modules to update the immediate values.
+ */
void immediate_update(int lock)
{
/* Core kernel immediates */
@@ -98,11 +107,7 @@ void immediate_update(int lock)
}
EXPORT_SYMBOL_GPL(immediate_update);
-/*
- * Update the immediate values to the state of the variables they refer to. It
- * is done before SMP is active, at the very beginning of start_kernel().
- */
-void __init immediate_update_early_range(const struct __immediate *begin,
+static void __init immediate_update_early_range(const struct __immediate
*begin,
const struct __immediate *end)
{
const struct __immediate *iter;
@@ -111,7 +116,12 @@ void __init immediate_update_early_range
arch_immediate_update_early(iter);
}
-
+/**
+ * immediate_update_early - Update immediate values at boot time
+ *
+ * Update the immediate values to the state of the variables they refer to. It
+ * is done before SMP is active, at the very beginning of start_kernel().
+ */
void __init immediate_update_early(void)
{
immediate_update_early_range(__start___immediate, __stop___immediate);
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Text Edit Lock - x86_64 kerneldoc implementation
Text Edit Lock - x86_64 kerneldoc implementation
Add kerneldoc to text edit lock x86_64 API.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86_64/mm/init.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
Index: linux-2.6-lttng/arch/x86_64/mm/init.c
===
--- linux-2.6-lttng.orig/arch/x86_64/mm/init.c 2007-07-15 19:01:50.0
-0400
+++ linux-2.6-lttng/arch/x86_64/mm/init.c 2007-07-15 19:02:18.0
-0400
@@ -617,8 +617,13 @@ void mark_rodata_ro(void)
global_flush_tlb();
}
-/*
- * Mark kernel text pages writable.
+/**
+ * kernel_text_mark_rw - Mark kernel text RW
+ * @address:location of the code
+ * @len:size of code to mark
+ *
+ * Mark the kernel text pages writable so they can safely written to. This is
+ * useful for code patching.
*/
void kernel_text_mark_rw(unsigned long address, size_t len)
{
@@ -636,6 +641,13 @@ void kernel_text_mark_rw(unsigned long a
}
EXPORT_SYMBOL_GPL(kernel_text_mark_rw);
+/**
+ * kernel_text_unmark -Mark kernel text back to its original flags
+ * @address:location of the code
+ * @len:size of code to mark
+ *
+ * Mark the kernel text back to its original flags.
+ */
void kernel_text_unmark(unsigned long address, size_t len)
{
if (kernel_text_is_ro && address >= PFN_ALIGN(_text)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
Hi. On Monday 16 July 2007 09:15:47 Alan Stern wrote: > On Sun, 15 Jul 2007 [EMAIL PROTECTED] wrote: > > > >> for a pure hibernate mode, you will be powering off the box after saving > > >> the suspend image. why are there any special ACPI modes involved? > > > > > > Because, for example, on my machine the status of power supply (present > > > vs not present) is not updated correctly after the restore if ACPI callbacks > > > aren't used during the hibernation. That's just experience and it's in line > > > with the ACPI spec. > > > > so if a machine is actually powered off the /dev/suspend process won't > > work? > > > > remember that the system may run a different OS between the hibernate and > > the resume, makeing any assumptions about what state the hardware is in > > when you start the resume is a problem. > > As I understand it, running a different OS between the hibernate and > the resume would violate the ACPI spec. Well then, I know one or two people who would argue that the ACPI spec is faulty. :\ Regards, Nigel -- Nigel Cunningham Christian Reformed Church of Cobden 103 Curdie Street, Cobden 3266, Victoria, Australia Ph. +61 3 5595 1185 / +61 417 100 574 Communal Worship: 11 am Sunday. pgp3glbzudcGB.pgp Description: PGP signature
[PATCH] Text Edit Lock - i386 kerneldoc implementation
Text Edit Lock - i386 kerneldoc implementation
Add kerneldoc to text edit lock i386 API.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
arch/i386/mm/init.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
Index: linux-2.6-lttng/arch/i386/mm/init.c
===
--- linux-2.6-lttng.orig/arch/i386/mm/init.c2007-07-15 18:59:31.0
-0400
+++ linux-2.6-lttng/arch/i386/mm/init.c 2007-07-15 19:00:05.0 -0400
@@ -826,9 +826,13 @@ void mark_rodata_ro(void)
global_flush_tlb();
}
-/*
- * Lock the kernel text for mutual write exclusion.
- * Make sure the pages are writable.
+/**
+ * kernel_text_mark_rw - Mark kernel text RW
+ * @address:location of the code
+ * @len:size of code to mark
+ *
+ * Mark the kernel text pages writable so they can safely written to. This is
+ * useful for code patching.
*/
void __kprobes kernel_text_mark_rw(unsigned long address, size_t len)
{
@@ -846,6 +850,13 @@ void __kprobes kernel_text_mark_rw(unsig
}
EXPORT_SYMBOL_GPL(kernel_text_mark_rw);
+/**
+ * kernel_text_unmark -Mark kernel text back to its original flags
+ * @address:location of the code
+ * @len:size of code to mark
+ *
+ * Mark the kernel text back to its original flags.
+ */
void __kprobes kernel_text_unmark(unsigned long address, size_t len)
{
if (kernel_text_is_ro && address >= PFN_ALIGN(_text)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Text Edit Lock - Architecture Independent Code for Implementation
Text Edit Lock - Architecture Independent Code - kerneldoc implementation
Add kerneldoc to text edit lock API.
Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
---
mm/memory.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
Index: linux-2.6-lttng/mm/memory.c
===
--- linux-2.6-lttng.orig/mm/memory.c2007-07-15 18:56:32.0 -0400
+++ linux-2.6-lttng/mm/memory.c 2007-07-15 18:57:18.0 -0400
@@ -2820,9 +2820,12 @@ int access_process_vm(struct task_struct
}
EXPORT_SYMBOL_GPL(access_process_vm);
-/*
- * Lock the kernel text for mutual write exclusion. Used for dynamic code
- * patching.
+/**
+ * kernel_text_lock - Take the kernel text modification lock
+ *
+ * Insures mutual write exclusion of kernel and modules text live text
+ * modification. Should be used for code patching.
+ * Users of this lock can sleep.
*/
void __kprobes kernel_text_lock(void)
{
@@ -2830,6 +2833,13 @@ void __kprobes kernel_text_lock(void)
}
EXPORT_SYMBOL_GPL(kernel_text_lock);
+/**
+ * kernel_text_unlock - Release the kernel text modification lock
+ *
+ * Insures mutual write exclusion of kernel and modules text live text
+ * modification. Should be used for code patching.
+ * Users of this lock can sleep.
+ */
void __kprobes kernel_text_unlock(void)
{
mutex_unlock(_mutex);
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Linux Kernel Markers - Architecture Independent Code - kerneldoc
Please drop, will be replaced by
linux-kernel-markers-architecture-independent-code-kerneldoc-implementation.patch
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> Linux Kernel Markers - Architecture Independent Code - kerneldoc
>
> Add kerneldoc to Linux Kernel Markers API.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> ---
> include/linux/marker.h | 108
> -
> 1 file changed, 99 insertions(+), 9 deletions(-)
>
> Index: linux-2.6-lttng/include/linux/marker.h
> ===
> --- linux-2.6-lttng.orig/include/linux/marker.h 2007-07-14
> 20:58:16.0 -0400
> +++ linux-2.6-lttng/include/linux/marker.h2007-07-14 21:16:01.0
> -0400
> @@ -20,6 +20,15 @@
> struct module;
> struct __mark_marker;
>
> +/**
> + * marker_probe_func - Type of a marker probe function
> + * @mdata: pointer of type struct __mark_marker
> + * @fmt: format string
> + * @...: variable argument list
> + *
> + * Type of marker probe functions. They receive the mdata and need to parse
> the
> + * format string to recover the variable argument list.
> + */
> typedef void marker_probe_func(const struct __mark_marker *mdata,
> const char *fmt, ...);
>
> @@ -88,18 +97,36 @@ extern void module_marker_update(struct
> static inline void module_marker_update(struct module *mod) { }
> #endif /* CONFIG_MARKERS */
>
> -/* Marker with default behavior */
> +/**
> + * trace_mark - Marker using code patching
> + * @name: marker name, not quoted.
> + * @format: format string
> + * @args...: variable argument list
> + *
> + * Places a marker using optimized code patching technique (immediate_if ())
> + * to be enabled.
> + */
> #define trace_mark(name, format, args...) \
> __trace_mark(0, name, format, ## args)
> -/*
> - * Map to the generic marker. Should be used for markers in __init and __exit
> - * functions and in lockdep code.
> +
> +/**
> + * _trace_mark - Marker using variable read
> + * @name: marker name, not quoted.
> + * @format: format string
> + * @args...: variable argument list
> + *
> + * Places a marker using a standard memory read (_immediate_if ()) to be
> + * enabled. Should be used for markers in __init and __exit functions and in
> + * lockdep code.
> */
> #define _trace_mark(name, format, args...) \
> __trace_mark(1, name, format, ## args)
>
> #define MARK_MAX_FORMAT_LEN 1024
> -/* Pass this as a format string for a marker with no argument */
> +
> +/**
> + * MARK_NOARGS - Format string for a marker with no argument.
> + */
> #define MARK_NOARGS " "
>
> /* To be used for string format validity checking with gcc */
> @@ -109,27 +136,90 @@ static inline void __mark_check_format(c
>
> extern marker_probe_func __mark_empty_function;
>
> -/*
> - * Connect a probe to a markers.
> +/**
> + * marker_probe_register - Connect a probe to a marker
> + * @name: marker name
> + * @format: format string
> + * @probe: probe handler
> + * @pdata: probe private data
> + *
> * pdata must be a valid allocated memory address, or NULL.
> + * Returns 0 if ok, error value on error.
> */
> extern int marker_probe_register(const char *name, const char *format,
> marker_probe_func *probe, void *pdata);
>
> -/*
> +/**
> + * marker_probe_unregister - Disconnect a probe from a marker
> + * @name: marker name
> + *
> * Returns the pdata given to marker_probe_register.
> */
> extern void *marker_probe_unregister(const char *name);
> -/*
> +
> +/**
> + * marker_probe_unregister - Disconnect a probe from a marker
> + * @pdata: probe private data
> + *
> * Unregister a marker by providing the registered pdata.
> + * Returns the pdata given to marker_probe_register.
> */
> extern void *marker_probe_unregister_pdata(void *pdata);
>
> +/**
> + * marker_arm - Arm a marker
> + * @name: marker name
> + *
> + * Activate a marker. It keeps a reference count of the number of
> + * arming/disarming done.
> + * Returns 0 if ok, error value on error.
> + */
> extern int marker_arm(const char *name);
> +
> +/**
> + * marker_disarm - Disarm a marker
> + * @name: marker name
> + *
> + * Disarm a marker. It keeps a reference count of the number of
> arming/disarming
> + * done.
> + * Returns 0 if ok, error value on error.
> + */
> extern int marker_disarm(const char *name);
> +
> +/**
> + * marker_get_first - Get first marker to start iteration
> + *
> + * Get the first marker found in the kernel. It should have a matching
> + * marker_release.
> + */
> extern struct __mark_marker *marker_get_first(void);
> +
> +/**
> + * marker_get_next - Get next marker of an iteration
> + * @iter: previous marker
> + *
> + * Get the next marker found in the kernel. It should get its previous marker
> + * from either marker_get_first() or marker_get_next().
> + */
> extern struct __mark_marker *marker_get_next(struct
Re: [PATCH] Text Edit Lock - i386 kerneldoc
Please drop, will be replaced by
text-edit-lock-i386-kerneldoc-implementation.patch
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> Text Edit Lock - i386 kerneldoc
>
> Add kerneldoc to text edit lock i386 API.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> ---
> include/asm-i386/cacheflush.h | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> Index: linux-2.6-lttng/include/asm-i386/cacheflush.h
> ===
> --- linux-2.6-lttng.orig/include/asm-i386/cacheflush.h2007-07-14
> 20:23:01.0 -0400
> +++ linux-2.6-lttng/include/asm-i386/cacheflush.h 2007-07-14
> 20:24:17.0 -0400
> @@ -35,8 +35,25 @@ void kernel_map_pages(struct page *page,
> #ifdef CONFIG_DEBUG_RODATA
> void mark_rodata_ro(void);
>
> -/* mark kernel text pages writable */
> +/**
> + * kernel_text_mark_rw - Mark kernel text RW
> + * @address:location of the code
> + * @len:size of code to mark
> + *
> + * Mark the kernel text pages writable so they can safely written to. This is
> + * useful for code patching.
> +*/
> +
> extern void kernel_text_mark_rw(unsigned long address, size_t len);
> +
> +/**
> + * kernel_text_unmark -Mark kernel text back to its original flags
> + * @address:location of the code
> + * @len:size of code to mark
> + *
> + * Mark the kernel text back to its original flags.
> + */
> +
> extern void kernel_text_unmark(unsigned long address, size_t len);
> #else
> static inline void kernel_text_mark_rw(unsigned long address, size_t len) { }
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Text Edit Lock - x86_64 kerneldoc
Please drop, will be replaced by
text-edit-lock-x86_64-kerneldoc-implementation.patch
* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> Text Edit Lock - x86_64 kerneldoc
>
> Add kerneldoc to text edit lock x86_64 API.
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> ---
> include/asm-x86_64/cacheflush.h | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
>
> Index: linux-2.6-lttng/include/asm-x86_64/cacheflush.h
> ===
> --- linux-2.6-lttng.orig/include/asm-x86_64/cacheflush.h 2007-07-14
> 20:25:49.0 -0400
> +++ linux-2.6-lttng/include/asm-x86_64/cacheflush.h 2007-07-14
> 20:25:50.0 -0400
> @@ -32,8 +32,25 @@ void clflush_cache_range(void *addr, int
> #ifdef CONFIG_DEBUG_RODATA
> void mark_rodata_ro(void);
>
> -/* mark kernel text pages writable */
> +/**
> + * kernel_text_mark_rw - Mark kernel text RW
> + * @address:location of the code
> + * @len:size of code to mark
> + *
> + * Mark the kernel text pages writable so they can safely written to. This is
> + * useful for code patching.
> +*/
> +
> extern void kernel_text_mark_rw(unsigned long address, size_t len);
> +
> +/**
> + * kernel_text_unmark -Mark kernel text back to its original flags
> + * @address:location of the code
> + * @len:size of code to mark
> + *
> + * Mark the kernel text back to its original flags.
> + */
> +
> extern void kernel_text_unmark(unsigned long address, size_t len);
> #else
> static inline void kernel_text_mark_rw(unsigned long address, size_t len) { }
> --
> Mathieu Desnoyers
> Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
> OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
On Mon, 16 Jul 2007, Rafael J. Wysocki wrote: On Sunday, 15 July 2007 21:23, [EMAIL PROTECTED] wrote: On Sun, 15 Jul 2007, Rafael J. Wysocki wrote: I think this is far more complicated then it needs to be. it sounds like it should be possible to do the following 1. figure out what pages should be backed up (creating a data structure to hold them) That should be done after step 2, because the memory contents can change in this step. no, this needs to be done by the main kernel, becouse only it knows how to find this info. the kernel that you kexec into could be very different (including different versions) and the ways to identify this data is not part of any existing API If the memory contents changes in step 2, then the information collected by the main kernel will be inaccurate. why would the memory use change when the new kernel is run? is it becouse of whatever it does to the devices for the hand-off? Yes, I think so, although I'm not sure, because I don't know what happens to devices during a "normal" kexec. is this a matter of running some test to find out, or is this a question for the kexec implemantors? during the wakeup stage, I thought you said that al that was needed was to feed the suspend image to /dev/suspend and the kernel in the suspend image would re-probe, or otherwise re-initialize all the devices it needs. am I misunderstanding this? Perhaps. Currently, the hibernated kernel will run device_resume() after the restore, which is not exactly compatible with what kexec does. but kexec isn't needed during the restore process, is it? Generally, it's not needed. _However_, the current handling of devices is such that: (a) hibernated kernel uses device_suspend() to put them into low power states and creates the image (b) hibernated kernel uses device_resume() to get devices back to work and saves the image (c) during the restore the boot kernel loads the image and uses device_suspend() to prepare devices for the "old" kernel (d) hibernated kernel gets control and uses device_resume() to get devices back to work. Now, if you use kexec instead of (a) and (b), then whatever it does to devices is generally incompatible with the device_resume() in (d) (because, for instance, some device driver's .resume() routine may expect some data to be saved by the corresponding .suspend() at specific locations). ok, this means that the resume operation is not a solved problem (at least for the kexec process) now, one possible approach to this (and this may be what Ying Huang it thinking of) would be to have the restore process be 1. boot the normal kernel with a dummy userspace, initializeing all devices 2. kexec to the hibernate kernel 3. the hibernate kernel's userspace overwrites all memory from the origional system that was saved 4. kexec from the hibernate kernel back to the origional kernel the ugly part here is the need for the dummy userspace in step #1 so that it doesn't try to access the wrong things. now, it may be that the kernel boot in step 1 doesn't need to be able to initialize all drivers for things to work in step 4, in which case things are much simpler (but you still may need the three kernel hop so that the final kernel is running in the same addresses that it started in. David Lang - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Text Edit Lock - Architecture Independent Code - kerneldoc
Please drop. Will be replaced by text-edit-lock-architecture-independent-code-kerneldoc-implementation.patch * Mathieu Desnoyers ([EMAIL PROTECTED]) wrote: > Text Edit Lock - Architecture Independent Code - kerneldoc > > Add kerneldoc to text edit lock API. > > Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> > CC: [EMAIL PROTECTED] > --- > include/linux/memory.h | 17 +++-- > 1 file changed, 15 insertions(+), 2 deletions(-) > > Index: linux-2.6-lttng/include/linux/memory.h > === > --- linux-2.6-lttng.orig/include/linux/memory.h 2007-07-14 > 20:08:50.0 -0400 > +++ linux-2.6-lttng/include/linux/memory.h2007-07-14 20:18:13.0 > -0400 > @@ -86,11 +86,24 @@ extern int remove_memory_block(unsigned > register_memory_notifier(##_mem_nb); \ > } > > -/* > - * Take and release the kernel text modification lock, used for code > patching. > +/** > + * kernel_text_lock - Take the kernel text modification lock > + * > + * Insures mutual write exclusion of kernel and modules text live text > + * modification. Should be used for code patching. > * Users of this lock can sleep. > */ > + > extern void kernel_text_lock(void); > + > +/** > + * kernel_text_unlock - Release the kernel text modification lock > + * > + * Insures mutual write exclusion of kernel and modules text live text > + * modification. Should be used for code patching. > + * Users of this lock can sleep. > + */ > + > extern void kernel_text_unlock(void); > > #endif /* _LINUX_MEMORY_H_ */ > -- > Mathieu Desnoyers > Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal > OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patches for REALLY TINY 386 kernels
[ the off-topic zillion-ways-to-do-same-thing-in-*nix sub-thread ] On 7/16/07, Arnd Bergmann <[EMAIL PROTECTED]> wrote: On Monday 16 July 2007, Satyam Sharma wrote: > > Yeah. I was going for the general principle :) > > Even simpler to add --exclude-from=.gitignore to diff > Or build in a separate object directory, using the O=$my_objdir Kbuild option. That has a number of addition advantages, e.g. you can easily clean your object files using 'rm -rf $my_objdir' and if you grep -r the source, you don't find your search string in generated files. Or just "cp -al" to create multiple trees at (almost) no disk cost that won't interfere with each other in any way, and makes the development process / generating patchsets trifle easier as well ... Or best of all, just start using git if you can ... ... ok, back to work now. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Sun, 15 Jul 2007, Al Boldi wrote: > Alan Stern wrote: > > On Sun, 15 Jul 2007, Al Boldi wrote: > > > > If possible, during a restore devices should be brought back to > > > > the same state in which they were before the corresponding > > > > hibernation. Of course in some situations it might be impossible to > > > > do that (eg. the user connected the hibernated system to a different > > > > IP subnet and then restored), but as a general rule, we should do our > > > > best to restore the state of devices, which is directly related to > > > > point (5) above. > > > > > > This part could easily be handled by the normal kernel before and after > > > resume. > > > > I agree with you except for the word "easily". And there are some > > things the kernel simply punts on (I'm thinking of the current VGA > > font). > > Why; can you explain? >From personal experience I can assure you that it hasn't been easy getting the USB subsystem to restore devices following a hibernate. (In fact the current implementation goes against the spirit, if not the letter, of the USB spec.) And making it work requires user intervention. As for the VGA font, the effect is easy to see: Run setfont before hibernating; when you resume the original font will be back. The kernel simply does not bother to save the VGA font information across a hibernate. > > > This should be the responsibility of the kexec'd hibernating kernel. > > > Note though in (6), the normal kernel takes care of preparing devices, > > > then the hibernating kernel dumps the image and either calls S4 or S3. > > > On resume from S3 it can immediately switch over to the normal kernel, > > > and from S4 the known bootup would occur. > > > > Is it really that simple? Somehow I doubt it. In order for some > > devices to remain available for the kexec'd kernel to use, they cannot > > be suspended at the ACPI level. So the kexec'd kernel will have to > > handle the ACPI requirements for those devices. Likewise, it would > > have to handle the ACPI interactions which need to be done after all > > devices are prepared for the transition to S3 or S4. > > Ok, after applying the latest kexec patches, I was able to use the kexec'd > kernel to suspend to ram and resume to the normal kernel, while working > under a full-blown X session. It went without a hitch. All that is needed > now are the dump/restore hibernation-image routines. That's exactly my point. While doing suspend-to-RAM from a kexec'd kernel may be simple, saving the hibernation image will add complications. > > > The latest hibernating kexec patches boot a kexec'd modular kernel with > > > initramfs into [EMAIL PROTECTED] in less than one second. Switch-back > > > is almost instant. Add to this the time required to either store or > > > restore the image, and it may be obvious that this approach isn't > > > slower, but maybe even faster than the current swsusp. > > > > Does that include the time required for probing PCI buses? On my > > desktop system, PCI probing incurs a five-second timeout delay because > > of a bug in the BIOS's USB firmware. > > Using a modular kernel you would only insmod those modules that you need to > dump the image, which is mainly the diskdriver. If you wanted to dump it > onto USB flash, then you would insmod that driver, and if that driver is > slow due to a bug, then a fix should be in order. I said nothing about dumping onto USB flash. I was referring to PCI probing; presumably any reasonable kernel for desktop/laptop systems will include PCI support. And the bug isn't in Linux; it is in the firmware. There's no way to fix it short of a BIOS upgrade (and this particular BIOS is no longer supported). Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] minimal fixes for drivers/usb/gadget/m66592-udc.c
On Sun, Jul 15, 2007 at 04:18:10PM -0700, David Brownell wrote: > Re the leaks, in probe() request_irq() isn't cleaned up ... but it > looked to me like the rest of the allocations did get cleaned up > afer probe() errors. But remove() does indeed leak the memory you > highlighted. Why not make ep0_buf a 16bit field in that struct? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Oops... not sure why.
On Sun, Jul 15, 2007 at 12:26:27PM -0400, Russell Harmon wrote: > Hey all, just updated to 2.6.22.1, and have been getting the following > oops rather often in my dmesg. It eventually makes it so no programs > will start, and I lose internet connectivity and so have to reboot. I > have a centrino duo system running SMP. > > I'm using SLAB. You told much but missed the most important point: Whatever you call "2.6.22.1" isn't the vanilla 2.6.22.1 kernel from ftp.kernel.org but the 2.6.22.1 kernel with a huge pile of external drivers and/or patches, and therefore off-topic on this list. Since your Oops involves unionfs that is not part of the 2.6.22.1 kernel contacting the unionfs developers might be a good starting point for you for looking for help. > Thanks > ~Russ > > BUG: unable to handle kernel NULL pointer dereference at virtual > address > printing eip: > > *pde = > Oops: [#2] > SMP > Modules linked in: snd_seq snd_seq_device snd_hda_intel snd_pcm > snd_timer snd snd_page_alloc rlocate tp_smapi thinkpad_ec iwl3945 > e1000 firewire_ohci firewire_core > CPU:0 > EIP:0060:[<>]Not tainted VLI > EFLAGS: 00010246 (2.6.22-kamikaze1-r1 #12) > EIP is at run_init_process+0x4fefff50/0x20 > eax: e6299800 ebx: ecx: b190d460 edx: b157cd40 > esi: b157cd40 edi: f6af0ee4 ebp: esp: e4cb1c5c > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process gnome-pty-helpe (pid: 9708, ti=e4cb task=f75b3a30 > task.ti=e4cb) > Stack: b014b22e 00d0 e6299800 e6299800 f6af0e40 e6299140 > b014d370 > e6299800 b142d680 b01eeb24 e6299800 b142d680 e6299800 b142d680 > > b17a4a00 b0151c70 00d0 e4cb1d0c f607cebc f607ceb0 > e6299140 > Call Trace: > [] read_cache_page_async+0x8e/0x160 > [] read_cache_page+0x10/0x50 > [] unionfs_readpage+0x84/0x1d0 > [] __do_page_cache_readahead+0x1f0/0x2a0 > [] dequeue_entity+0x7e/0xb0 > [] dequeue_task+0x27/0x40 > [] update_stats_wait_end+0x9b/0xc0 > [] ra_submit+0xd0/0xe0 > [] page_cache_readahead_adaptive+0x108/0x5e0 > [] unionfs_commit_write+0x64/0x1e0 > [] do_generic_mapping_read+0x3a1/0x600 > [] generic_file_aio_read+0xd3/0x1d0 > [] file_read_actor+0x0/0x120 > [] unionfs_aio_read+0x51/0xc0 > [] do_sync_read+0xc7/0x110 > [] autoremove_wake_function+0x0/0x50 > [] enqueue_hrtimer+0x72/0x100 > [] hrtimer_start+0xc7/0x140 > [] unionfs_read+0x42/0xa0 > [] vfs_read+0xbc/0x160 > [] unionfs_read+0x0/0xa0 > [] sys_read+0x41/0x70 > [] sysenter_past_esp+0x5f/0x85 > === > Code: Bad EIP value. > EIP: [<>] run_init_process+0x4fefff50/0x20 SS:ESP 0068:e4cb1c5c cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patches for REALLY TINY 386 kernels
On Monday 16 July 2007, Satyam Sharma wrote: > > Yeah. I was going for the general principle :) > > Even simpler to add --exclude-from=.gitignore to diff > Or build in a separate object directory, using the O=$my_objdir Kbuild option. That has a number of addition advantages, e.g. you can easily clean your object files using 'rm -rf $my_objdir' and if you grep -r the source, you don't find your search string in generated files. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] minimal fixes for drivers/usb/gadget/m66592-udc.c
Re the leaks, in probe() request_irq() isn't cleaned up ... but it looked to me like the rest of the allocations did get cleaned up afer probe() errors. But remove() does indeed leak the memory you highlighted. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Sun, 15 Jul 2007 [EMAIL PROTECTED] wrote: > > (1) Filesystems mounted before the hibernation are untouchable > > > >When there's a memory snapshot, either in the form of a hibernation > > image, > >or in the form of the "old" kernel and processes available to the "new" > >kexeced kernel responsible for saving their memory, the filesystems > > mounted > >before the hibernation should not be accessed, even for reading, because > >that would cause their on-disk state to be inconsistent with the snapshot > >and might lead to a filesystem corruption. > > AFAIK this is only the case with ext3, all other filesystems could be > accessed read-only safely > > this is arguably a bug with ext3 (and has been discussed as such), but > right now the ext3 team has decided not to change this bahavior so > hibernate needs to work around it. but don't mistake a work-around for a > single (admittedly very popular) filesystem with a hard and fast > directive. Isn't is possible to avoid this problem by mounting an ext3 filesystem as readonly ext2? Provided the filesystem isn't dirty it should be doable. (And provided the filesystem doesn't use any ext3 extensions that are incompatible with ext2.) Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] msleep() with hrtimers
On Monday 16 July 2007, Jonathan Corbet wrote: > Here's another approach: a reimplementation of msleep() and > msleep_interruptible() using hrtimers. On a system without real > hrtimers this code will at least drop down to single-jiffy delays much > of the time (though not deterministically so). On my x86_64 system with > Thomas's hrtimer/dyntick patch applied, msleep(1) gives almost exactly > what was asked for. This reminds me of a patch I did some time ago, without ever getting any feedback on it: http://lkml.org/lkml/2007/3/4/165 In addition to just msleep, it converted all users of schedule_timeout() as well as sys_*select(). I actually ran with that patch on my main worstation for a few weeks, and while it did not crash, I saw some strange behaviour after all. Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Sun, 15 Jul 2007 [EMAIL PROTECTED] wrote: > >> for a pure hibernate mode, you will be powering off the box after saving > >> the suspend image. why are there any special ACPI modes involved? > > > > Because, for example, on my machine the status of power supply (present > > vs not present) is not updated correctly after the restore if ACPI callbacks > > aren't used during the hibernation. That's just experience and it's in line > > with the ACPI spec. > > so if a machine is actually powered off the /dev/suspend process won't > work? > > remember that the system may run a different OS between the hibernate and > the resume, makeing any assumptions about what state the hardware is in > when you start the resume is a problem. As I understand it, running a different OS between the hibernate and the resume would violate the ACPI spec. Alan Stern - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Hibernation considerations
On Monday, 16 July 2007 00:42, [EMAIL PROTECTED] wrote: > On Mon, 16 Jul 2007, Rafael J. Wysocki wrote: > > > On Sunday, 15 July 2007 22:13, [EMAIL PROTECTED] wrote: > >> On Sun, 15 Jul 2007, Rafael J. Wysocki wrote: > >> > >>> Hi, > >>> > >>> Since many alternative approaches to hibernation are now being considered > >>> and > >>> discussed, I thought it might be a good idea to list some things that in > >>> my not > >>> so humble opinion should be taken care of by any hibernation framework. > >>> They > >>> are listed below, not in any particular order, because I think they all > >>> are > >>> important. Still, I might have forgotten something, so everyone with > >>> experience in implementing hibernation, especially Pavel and Nigel, please > >>> check if the list is complete. > >>> > >>> (1) Filesystems mounted before the hibernation are untouchable > >>> > >>>When there's a memory snapshot, either in the form of a hibernation > >>> image, > >>>or in the form of the "old" kernel and processes available to the "new" > >>>kexeced kernel responsible for saving their memory, the filesystems > >>> mounted > >>>before the hibernation should not be accessed, even for reading, > >>> because > >>>that would cause their on-disk state to be inconsistent with the > >>> snapshot > >>>and might lead to a filesystem corruption. > >> > >> AFAIK this is only the case with ext3, all other filesystems could be > >> accessed read-only safely > >> > >> this is arguably a bug with ext3 (and has been discussed as such), but > >> right now the ext3 team has decided not to change this bahavior so > >> hibernate needs to work around it. but don't mistake a work-around for a > >> single (admittedly very popular) filesystem with a hard and fast > >> directive. > >> > >>> (2) Swap space in use before the hibernation must be handled with care > >>> > >>>If swap space is used for saving the memory snapshot, the > >>> snapshot-saving > >>>application (or kernel) must be careful enough not to overwrite swap > >>> pages > >>>that contain valid memory contents stored in there before the > >>> hibernation. > >> > >> true, in fact, given that many distros and live-CD's autodetect swap > >> partitions and consider them fair game, I would argue that the best thing > >> to do would be to have the main system free up it's swap partitions before > >> going into hibernation. > >> > >> however, this could be a decision of the particular hibernate routines. > >> > >> for the kexec approach the mapping of what swap pages are in use is one > >> more chunk of data that needs to be assembled and made available through a > >> defined interface. > >> > >>> (4) The user should be able to limit the size of a hibernation image > >>> > >>>There are a couple of reasons of that. For example, the storage space > >>>used for saving the image may be smaller than the entire RAM or the > >>> user > >>>may want the image to be saved quickier. > >> > >> it may make sense for this to be split into hard and soft limits. > >> > >> if you try to save more then the storage space can hold you cannot > >> continue, but if you are just a little over the arbatrary size limit that > >> was set to make things fast you are better off saving things as-is then > >> punting, going back to the system, trying to free more ram, and trying a > >> hibernate again. > >> > >> with the kexec approach the enforcment of these limits is also split into > >> two sections. > >> > >> when the hibernate command is given in the main kernel, it's userspace > >> needs to follow some policy to decide how much (if any) memory to free. > > > > How are you going to achieve this without (a) having hibernation-aware > > user space or (b) the freezer? > > the hibernate command is a userspace command, but the fact that other > things in userspace are running at the same time is exactly why this is > only an estimate and best-effort as I said in the paragraph below. > > >> but since the kexec command and the preporation of the devices can change > >> the memory, the estimates done by the first kernel's userspace are just > >> that, estimates. > >> > >>> (7) On ACPI systems special platform-related actions have to be carried > >>> out at > >>>the right points, so that the platform works correctly after the > >>> restore > >>> > >>>The ACPI specification requires us to invoke some global ACPI methods > >>>during the hibernation and during the restore. Moreover, the ordering > >>> of > >>>code related to these ACPI methods may not be arbitrary (eg. some of > >>>them have to be executed after devices are put into low power states > >>> etc.). > >> > >> for a pure hibernate mode, you will be powering off the box after saving > >> the suspend image. why are there any special ACPI modes involved? > > > > Because, for example, on my machine the status of power supply (present > > vs not present) is not updated correctly
Re: Patches for REALLY TINY 386 kernels
On 7/16/07, Nigel Cunningham <[EMAIL PROTECTED]> wrote: On Monday 16 July 2007 08:45:26 Alan Cox wrote: > > > These patches were written against the vanilla 2.6.21.1 kernel. They > > > will have no effect UNLESS you make menuconfig and explicitly enable > > > them there. > > > > Would you please make mrproper before preparing the patch? It's harder to read > > with all the "Only in..." lines. > > A lot simpler is to feed the patch through "grep -v" Yeah. I was going for the general principle :) Even simpler to add --exclude-from=.gitignore to diff There's a Documentation/dontdiff file I've come across as well, but that's horribly out-of-date and why it exists in Documentation/ I have no clue either. Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: *at syscalls for xattrs?
Al Viro wrote: > BTW, why is fstatat called fstatat and not statat? (Same goes for futimesat.) It does not take a file descriptor for the file argument. Otherwise we'd also need fopenat/funlinkat, etc. Any reasons? >>> Ulrich having an odd taste? >> Solaris compatibility. > > "Sun having no taste whatsoever" Yup. I filed an objection to this with the POSIX committee, but it was rejected :( -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Patches for REALLY TINY 386 kernels
On Monday 16 July 2007 08:45:26 Alan Cox wrote: > > > These patches were written against the vanilla 2.6.21.1 kernel. They > > > will have no effect UNLESS you make menuconfig and explicitly enable > > > them there. > > > > Would you please make mrproper before preparing the patch? It's harder to read > > with all the "Only in..." lines. > > A lot simpler is to feed the patch through "grep -v" Yeah. I was going for the general principle :) Nigel -- Nigel Cunningham Christian Reformed Church of Cobden 103 Curdie Street, Cobden 3266, Victoria, Australia Ph. +61 3 5595 1185 / +61 417 100 574 Communal Worship: 11 am Sunday. pgp5wimT9HSCB.pgp Description: PGP signature
Re: Patches for REALLY TINY 386 kernels
Jonathan Campbell wrote:
> I wrote a set of patches out of concern that even if you compile a 386
> kernel a lot of code irrelevent to legacy machines still remains. Things
> like the Pentium TSC register, DMI information, ESCD parsing, and the
> use of CPUID do not apply to these machines, but looking at System.map
> you can see they're still there.
>
> Already with these patches I can compile a zImage kernel that is 450kb
> large (890kb decompressed) with a small initramfs payload, floppy and
> kernel module support, FPU emulation, that can successfully boot on an
> ancient 386 laptop with only 1MB of extended memory. Eventually what I'd
> like to have is the ability to compile a pure 386 kernel with all
> non-386 functions removed (and perhaps the same for 486 machines).
>
> These patches were written against the vanilla 2.6.21.1 kernel. They
> will have no effect UNLESS you make menuconfig and explicitly enable
> them there.
These should all probably depend on EMBEDDED (which is the "allow
features to be disabled which would be dangerous for most people".)
CONFIG_X86_TSC, however, would be cleaner implemented by something like:
#ifdef CONFIG_X86_TSC
int disable_tsc;
#else
#define disable_tsc 1
#endif
... then gcc will optimize out the rest of the code.
The CPUID stuff hacks up the code quite a bt which makes it hard to
read. Can you abstract any of that code so it doesn't get so ugly?
Stuff like:
+#ifndef CONFIG_X86_DONT_CPUID
if (cpu_has_fxsr) {
/*
* Verify that the FXSAVE/FXRSTOR data will be 16-byte aligned.
@@ -1177,6 +1178,7 @@
set_in_cr4(X86_CR4_OSXMMEXCPT);
printk("done.\n");
}
+#endif
... is much better handled by forcing the value of the cpu_has_* macros
to zero, in which case gcc optimizes out the if clause. The current git
HEAD has handling of constant cpu_* going the other way, but it should
be easy enough to extend.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Patches for REALLY TINY 386 kernels
On Sun, Jul 15, 2007 at 02:00:29PM -0700, Jonathan Campbell wrote: > I wrote a set of patches out of concern that even if you compile a 386 > kernel a lot of code irrelevent to legacy machines still remains. Things > like the Pentium TSC register, DMI information, ESCD parsing, and the use > of CPUID do not apply to these machines, but looking at System.map you can > see they're still there. > > Already with these patches I can compile a zImage kernel that is 450kb > large (890kb decompressed) with a small initramfs payload, floppy and > kernel module support, FPU emulation, that can successfully boot on an > ancient 386 laptop with only 1MB of extended memory. Eventually what I'd > like to have is the ability to compile a pure 386 kernel with all non-386 > functions removed (and perhaps the same for 486 machines). >... Besides some issues with the patch itself you didn't provide the one important number: By how much does your patch decrease the size of the kernel? Also note that when aiming for a tiny kernel enabling module support is a huge mistake since it increases the amount of RAM used when running the kernel by at about 10%. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation
On Sunday, 15 July 2007 21:33, [EMAIL PROTECTED] wrote: > On Sun, 15 Jul 2007, Rafael J. Wysocki wrote: > > > On Saturday, 14 July 2007 23:34, [EMAIL PROTECTED] wrote: > >> On Sat, 14 Jul 2007, Rafael J. Wysocki wrote: > >> > >>> On Saturday, 14 July 2007 09:51, [EMAIL PROTECTED] wrote: > On Fri, 13 Jul 2007, Rafael J. Wysocki wrote: > > >> Ok, now we need a data channel from the old kernel to the hibernate > >> kernel, to the restore kernel. and the messier the memory layout the > >> larger this data channel needs to be (hmm, what's the status on the > >> memory > >> defrag patches being proposed?) if this list can be made small enough > >> it > >> would work to just have the old kernel put the data in a known > >> location in > >> ram, and let the other two parts find it (in ram for the hibernate > >> kernel, > >> in the hibernate image for the wakeup kernel). > > > > I think the hibernation kernel should mmap() the "old" kernel's (and > > it's > > processes') memory available for saving, so that the image-saving > > process > > can read its contents from the original locations. > > but I'll bet that not all kernels keep the info in the same place (and > probably not even in the same format). I'm suggesting that a standard be > defined for the format of the data and the location of a pointer to it > that will be maintained across kernel versions. > >>> > >>> Yes. > >>> > >>> The image-saving kernel needs to have access to the hibernated kernel's > >>> pages data, plus some additional information that should be passed in a > >>> standard format. > >> > >> but per stable-abi-nonsense the internal structure of the kernel's pages > >> data isn't an abi. so instead of figuring this out by pokeing around in > >> the memory of the old kernel and deciding what should be saved and what > >> shouldn't, the old kernel (which understands the memory structure) should > >> create a simple map of what should be backed up (either a bitmap or an > >> extent-style map, depending on how many holes there are expected to be) > >> and then provide that map to the new kernel. the new kernel (or more > >> precisely it's userspace) reads the pages it's told to read and writes > >> them somewhere. > > > > That's reasonable, but the "old" kernel can only do this after handling the > > shut down/quiescing of devices, when there is 100% guarantee that the memory > > contents will not change. > > Ok, that makes sense. and since part of what's being passed along here is > what ram is free as far as the outgoing kernel is concerned, this is > useful info for the new kernel for other situations, not just for the > hibernate operation, so this is probably a reasonable modification to the > kexec call in any case (although a crash-dump kernel may decide not to > trust this info and save everything, it's still useful to know what the > outgoing kernel considers free) > > >> since people are complaining about the amount of ram that a kexec > >> kernel > >> would take up I'm assuiming it's somethingmore complex then just a > >> bitmap > >> of all possible pages. > > > > No, it's just bitmaps, AFAICS, and the complaints are a bit overstated, > > IMO. ;-) > > 1 bit for each 4k means 1m bits for 4g of ram, or 128k of bitmaps, > growing > up to 1m of ram used for 32G of ram in the system. I guess this isn't bad > as long as it doesn't need to be contiguous for the new kernel to access > it. > > ok, that makes it a pretty trivial thing to work with. I just need to > learn how to find the bitmaps. > >>> > >>> They are created on the fly before the hibernation. The format is > >>> described in > >>> kernel/power/snapshot.c . > >> > >> I'll look through this file, but the format of this is an abi/api to the > >> userspace and should be documented outside of the code. > > > > Nope. The user space need not know anything about the image contents. > > > > The current implementation of the user space tools use the knowledge of the > > image header format, which is given by 'struct swsusp_info', defined in > > kernel/power/power.h . > > there are a couple factors here. > > 1. this needs to remain the same across different kernel versions. Not exactly. Whatever is after the image header may change at any time and the user space should not rely on that not changing. The header itself is a (slightly) different matter. > 2. this may or may not be created by userspace tools Well, the image header is not created by userspace tools and only read the image size from it. > both of these tend to imply that this is an interface to the world and > needs to be documented and stable. Well, it should be documented, but currently there's only one implementation of the userland tools and the authors of these know the format. ;-) Greetings, Rafael --
Re: panics with 16port Promise Supertrack EX Controller
Hello On Mon, Jul 09, 2007 at 11:59:36AM +1000, Nick Piggin wrote: > >Jul 8 00:19:13 dorade.cyberlink.ch EFLAGS: 00210046 > >(2.6.22-rc7-dorade #1) > >>The machine panics > >>after some days of running fine, the machine inst heavy loaded. > >>The Controller detects as stex device: > >kernel BUG at block/as-iosched.c:1084! > > > >BUG_ON(RB_EMPTY_ROOT(>sort_list[REQ_ASYNC])); > Could be a bug in the driver that just happens to be caught by AS checks. > If you could test another scheduler (boot with elevator=deadline or > elevator=cfq), > it might help give us an idea. Ok, I now switched to cfg, and the machine panicd again. Panic attached. Any help is appreciated. Flavio Curti -- http://no-way.org/~fcu/ blk_queue_end_tag: attempt to clear non-busy tag (1) [ cut here ] kernel BUG at block/ll_rw_blk.c:2758! invalid opcode: [#1] SMP Modules linked in: i2c_i801 i2c_core CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010002 (2.6.22.1-dorade #1) EIP is at __blk_put_request+0x74/0x80 eax: ebx: dae3e578 ecx: c02ac600 edx: esi: 00030784 edi: f7f28b24 ebp: f7f28b24 esp: c0621e50 ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process swapper (pid: 0, ti=c062 task=c05d8340 task.ti=c062) Stack: dae3e578 e2b5aac0 0001 scsi_end_request+0x94/0xe0 [] scsi_io_completion+0x86/0x3e0 [] del_timer+0x5a/0x70 [] sd_rw_intr+0x2b/0x200 [] stex_mu_intr+0x12e/0x540 [] scsi_finish_command+0x45/0x60 [] blk_done_softirq+0x58/0x70 [] __do_softirq+0x82/0x100 [] do_softirq+0x37/0x40 [] irq_exit+0x75/0x80 [] do_IRQ+0x40/0x80 [] getnstimeofday+0x36/0xd0 [] common_interrupt+0x23/0x28 [] mwait_idle_with_hints+0x46/0x60 [] cpu_idle+0x65/0x90 [] start_kernel+0x2ef/0x370 [] unknown_bootoption+0x0/0x250 === Code: 8b 57 24 89 d8 83 e6 01 e8 ca 1b eb ff 89 f2 89 f8 89 e9 5b 5e 5f 5d e9 3b ff last message repeated 2 times 89 da 89
