* Re: [PATCH] cgroups: don't cache common ancestor in task counter subsys
From: Li Zefan @ 2011-10-31 3:14 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Ben Blum, Andrew Morton, Frederic Weisbecker, Paul Menage, LKML
In-Reply-To: <20111027151230.GE7974@somewhere.redhat.com>
Frederic Weisbecker wrote:
> On Mon, Oct 17, 2011 at 01:27:53PM -0400, Ben Blum wrote:
>> On Mon, Oct 17, 2011 at 07:25:41PM +0200, Frederic Weisbecker wrote:
>>> When we rollback there, we are dealing with oldcgrp of the last thread
>>> we have treated. All threads in the rollback list don't necessary belonged
>>> to that old_cgroup.
>>>
>>> And we can't try to retrieve these old_cgroup through task_cgroup_from_root() because
>>> the threads might have exited and thus could be assigned to the init cgroup.
>>>
>>> I believe we need to cache these old cgroups in the flex array.
>>>
>>
>> Doing this would fulfill the "TODO" in cgroup_attach_proc for being able
>> to pass the oldcgrp for each task in the loop around the ss->attach
>> call, so if you do that, remove the corresponding comment. :)
>>
>> -- Ben
>
> I don't know, looking at the code, there is a separate issue to solve there.
> The old cgroup passed in ->attach() is the one of a random task from the thread
> group. The migrations that happen right before leave oldcgrp with the
> old cgroup of the last thread in the group.
>
> This doesn't seem to make any sense. As far as I checked this is only used
> by the cpuset subsystem that does a migration in cpuset_attach() from
> the old cgroup to the new.
>
> I'm not sure about the details but that looks buggy.
>
I think you're right, and Tejun's patchset happens to fix this bug in
cpuset_attach() - it gets the mm of the thread leader and do migration.
^ permalink raw reply
* Re: kernel panic on device removal when using a workqueue and delayed_work
From: Yong Zhang @ 2011-10-31 3:11 UTC (permalink / raw)
To: Frank Sch�fer; +Cc: linux-kernel
In-Reply-To: <4EADA32E.6030200@googlemail.com>
On Sun, Oct 30, 2011 at 08:19:10PM +0100, Frank Sch�fer wrote:
> Hi,
>
> with the following simple kernel module, I have a good chance to get
> a kernel panic when I unplug the device:
>
>
> #include <linux/workqueue.h>
> #include <linux/usb.h>
> #include <linux/module.h>
>
> MODULE_AUTHOR("Nobody");
> MODULE_DESCRIPTION("example driver for causing kernel panic");
> MODULE_LICENSE("GPL");
>
> static struct delayed_work poll_work;
>
> static void poll(struct work_struct *work)
> {
> schedule_delayed_work(&poll_work,
> msecs_to_jiffies(100));
> }
>
> static int test_probe(struct usb_interface *intf,
> const struct usb_device_id *id)
> {
> INIT_DELAYED_WORK(&poll_work, poll);
> schedule_delayed_work(&poll_work,
> msecs_to_jiffies(100));
> return 0;
> }
>
> static void test_disconnect(struct usb_interface *intf)
> {
> cancel_delayed_work_sync(&poll_work);
> }
>
> static const struct usb_device_id device_table[] = {
> {USB_DEVICE(0x1234, 0x5678)},
> {}
> };
>
> MODULE_DEVICE_TABLE(usb, device_table);
>
> static struct usb_driver test_driver = {
> .name = "test",
> .id_table = device_table,
> .probe = test_probe,
> .disconnect = test_disconnect,
> };
>
> static int __init test_mod_init(void)
> {
> return usb_register(&test_driver);
> }
>
> static void __exit test_mod_exit(void)
> {
> usb_deregister(&test_driver);
> }
>
> module_init(test_mod_init);
> module_exit(test_mod_exit);
>
>
>
>
> A picture of the backtrace (the machine immediately turns off
> without saving a backtrace) can be found at
>
> http://imageshack.us/photo/my-images/823/img075gv.jpg
>
> Kernel version is 3.1.0.
>
>
> This is the first time I'm using a workqueue, so there is a good
> chance that I missed something...
You should cancel the work you have armed before exit.
See cancel_delayed_work().
> Or is this a kernel bug ?
I don't think so.
Thanks,
Yong
^ permalink raw reply
* RE: JMicron Technology JMB362 JMB363 SError: { DevExch } ExpressCard, sometimes fails to boot
From: Aries Lee @ 2011-10-31 2:59 UTC (permalink / raw)
To: 'Tejun Heo', 'Orson'; +Cc: linux-ide
In-Reply-To: <20111030211240.GE7696@google.com>
Hi Tejun,
Is it possible to install windows OS on the same hardware,
If it still get the same error, that we can conclude it as a hardware issue.
------------------------------------------------
Aries Lee
JMicron Technology Corp.
1F, No.13, Innovation Road 1, Science-Based Industrial Park,
Hsin-Chu, Taiwan
Tel : 886-3-579-7389 ext:8829
-----------------------------------------------------Original Message-----
From: Tejun Heo [mailto:htejun@gmail.com] On Behalf Of Tejun Heo
Sent: Monday, October 31, 2011 5:13 AM
To: Orson
Cc: linux-ide@vger.kernel.org; arieslee@jmicron.com
Subject: Re: JMicron Technology JMB362 JMB363 SError: { DevExch }
ExpressCard, sometimes fails to boot
Hello,
(cc'ing Aries of jmicron)
On Mon, Oct 10, 2011 at 06:02:46PM +0300, Orson wrote:
> I tried my xpress54 card JMB362/363 on Debian Wheezy testing, with
> kernel 3.0.0-1-amd64 (Debian 3.0.0.-3).
>
> The card was inserted into the express slot without any external
> disk attached and I experienced the same problems I had been having
> with debian squeeze, perhaps even more consistently.
>
> I am now only using single port JMB 360 cards which operate flawlessly.
>
> I am attaching a kernel log with the said card inserted.
Hmmm.... it looks like the controller is continuously raising
connection status changed state and libata is faithfully trying to
probe whether new device appeared on the port. Does it work if you
plug an actual hard drive into the port? Looks more like wrong wiring
than anything else. Aries, any ideas?
ahci 0000:10:00.0: AHCI 0001.0000 32 slots 2 ports 3 Gbps 0x3 impl SATA
mode
ahci 0000:10:00.0: flags: 64bit ncq pm led clo pmp pio slum part
ahci 0000:10:00.0: setting latency timer to 64
scsi1 : ahci
ata1: SATA max UDMA/133 abar m8192@0xd0000000 port 0xd0000100 irq 16
ata2: SATA max UDMA/133 abar m8192@0xd0000000 port 0xd0000180 irq 16
ata1: SATA link down (SStatus 0 SControOct 9 23:45:46 hp-laptop kernel: [
1.414084] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0xe
frozen
ata1: irq_stat 0x00000040, connection status changed
ata1: SError: { PHYInt CommWake DevExch }
ata1: hard resetting link
ata1: COMRESET failed (errno=-32)
ata1: reset failed (errno=-32), retrying in 8 secs
ata1: limiting SATA link speed to 1.5 Gbps
ata1: hard resetting link
ata1: SATA link down (SStatus 0 SControl 310)
ata1: EH complete
ata1: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0xe frozen
ata1: irq_stat 0x00000040, connection status changed
ata1: SError: { PHYInt CommWake DevExch }
ata1: hard resetting link
ata1: COMRESET failed (errno=-32)
ata1: reset failed (errno=-32), retrying in 8 secs
ata1: hard resetting link
ata1: SATA link down (SStatus 0 SControl 310)
ata1: EH complete
ata1: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0xe frozen
ata1: irq_stat 0x00000040, connection status changed
ata1: SError: { PHYInt CommWake DevExch }
ata1: limiting SATA link speed to 1.5 Gbps
ata1: hard resetting link
ata1: SATA link down (SStatus 0 SControl 310)
ata1: EH complete
ata1: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0xe frozen
ata1: irq_stat 0x00000040, connection status changed
ata1: SError: { PHYInt CommWake DevExch }
ata1: limiting SATA link speed to 1.5 Gbps
ata1: hard resetting link
ata1: SATA link down (SStatus 0 SControl 310)
ata1: EH complete
ata1: exception Emask 0x10 SAct 0x0 SErr 0x4060000 action 0xe frozen
ata1: irq_stat 0x00000040, connection status changed
ata1: SError: { PHYInt CommWake DevExch }
ata1: limiting SATA link speed to 1.5 Gbps
ata1: hard resetting link
ata1: SATA link down (SStatus 0 SControl 310)
ata1: EH complete
(repeat...)
--
tejun
^ permalink raw reply
* [Qemu-devel] [PATCH] qed: adjust the way to get nb_sectors
From: Zhi Yong Wu @ 2011-10-31 3:01 UTC (permalink / raw)
To: qemu-devel; +Cc: kwolf, Zhi Yong Wu, stefanha
It is better to use qiov.size in qed-table.c to get nb_sectors than iov.iov_len.
Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
---
block/qed-table.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/qed-table.c b/block/qed-table.c
index f31f9ff..8ee8443 100644
--- a/block/qed-table.c
+++ b/block/qed-table.c
@@ -29,7 +29,7 @@ static void qed_read_table_cb(void *opaque, int ret)
{
QEDReadTableCB *read_table_cb = opaque;
QEDTable *table = read_table_cb->table;
- int noffsets = read_table_cb->iov.iov_len / sizeof(uint64_t);
+ int noffsets = read_table_cb->qiov.size / sizeof(uint64_t);
int i;
/* Handle I/O error */
@@ -65,7 +65,7 @@ static void qed_read_table(BDRVQEDState *s, uint64_t offset, QEDTable *table,
qemu_iovec_init_external(qiov, &read_table_cb->iov, 1);
aiocb = bdrv_aio_readv(s->bs->file, offset / BDRV_SECTOR_SIZE, qiov,
- read_table_cb->iov.iov_len / BDRV_SECTOR_SIZE,
+ qiov->size / BDRV_SECTOR_SIZE,
qed_read_table_cb, read_table_cb);
if (!aiocb) {
qed_read_table_cb(read_table_cb, -EIO);
@@ -160,7 +160,7 @@ static void qed_write_table(BDRVQEDState *s, uint64_t offset, QEDTable *table,
aiocb = bdrv_aio_writev(s->bs->file, offset / BDRV_SECTOR_SIZE,
&write_table_cb->qiov,
- write_table_cb->iov.iov_len / BDRV_SECTOR_SIZE,
+ write_table_cb->qiov.size / BDRV_SECTOR_SIZE,
qed_write_table_cb, write_table_cb);
if (!aiocb) {
qed_write_table_cb(write_table_cb, -EIO);
--
1.7.6
^ permalink raw reply related
* [PATCH] mfd: adp5520: Ensure setting bits if new value is different from the old value
From: Axel Lin @ 2011-10-31 3:00 UTC (permalink / raw)
To: linux-kernel; +Cc: Michael Hennerich, Samuel Ortiz, device-drivers-devel
Current code checks if all the bit_mask bits are all zero is wrong.
We need to write new value if the bit mask fields of new value is
not equal to old value.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/mfd/adp5520.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mfd/adp5520.c b/drivers/mfd/adp5520.c
index f1d8848..8d816cc 100644
--- a/drivers/mfd/adp5520.c
+++ b/drivers/mfd/adp5520.c
@@ -109,7 +109,7 @@ int adp5520_set_bits(struct device *dev, int reg, uint8_t bit_mask)
ret = __adp5520_read(chip->client, reg, ®_val);
- if (!ret && ((reg_val & bit_mask) == 0)) {
+ if (!ret && ((reg_val & bit_mask) != bit_mask)) {
reg_val |= bit_mask;
ret = __adp5520_write(chip->client, reg, reg_val);
}
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 6/6] ext4: reimplement ext4_find_delay_alloc_range on delayed extent tree
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4, Yongqiang Yang
In-Reply-To: <1320022547-2284-1-git-send-email-xiaoqiangnk@gmail.com>
ext4_find_delay_alloc_range is reimplemented on delayed extent tree.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
---
fs/ext4/ext4.h | 4 --
fs/ext4/ext4_extents.h | 3 +-
fs/ext4/extents.c | 109 +++++------------------------------------------
fs/ext4/inode.c | 53 +-----------------------
4 files changed, 14 insertions(+), 155 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 72c6b1e..9eacf5a 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -2296,14 +2296,10 @@ enum ext4_state_bits {
* never, ever appear in a buffer_head's state
* flag. See EXT4_MAP_FROM_CLUSTER to see where
* this is used. */
- BH_Da_Mapped, /* Delayed allocated block that now has a mapping. This
- * flag is set when ext4_map_blocks is called on a
- * delayed allocated block to get its real mapping. */
};
BUFFER_FNS(Uninit, uninit)
TAS_BUFFER_FNS(Uninit, uninit)
-BUFFER_FNS(Da_Mapped, da_mapped)
/*
* Add new method to test wether block and inode bitmaps are properly
diff --git a/fs/ext4/ext4_extents.h b/fs/ext4/ext4_extents.h
index a52db3a..14ef9f5 100644
--- a/fs/ext4/ext4_extents.h
+++ b/fs/ext4/ext4_extents.h
@@ -290,7 +290,6 @@ extern struct ext4_ext_path *ext4_ext_find_extent(struct inode *, ext4_lblk_t,
struct ext4_ext_path *);
extern void ext4_ext_drop_refs(struct ext4_ext_path *);
extern int ext4_ext_check_inode(struct inode *inode);
-extern int ext4_find_delalloc_cluster(struct inode *inode, ext4_lblk_t lblk,
- int search_hint_reverse);
+extern int ext4_find_delalloc_cluster(struct inode *inode, ext4_lblk_t lblk);
#endif /* _EXT4_EXTENTS */
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index ad6f5af..a18ff48 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -3260,112 +3260,27 @@ static int check_eofblocks_fl(handle_t *handle, struct inode *inode,
/**
* ext4_find_delalloc_range: find delayed allocated block in the given range.
*
- * Goes through the buffer heads in the range [lblk_start, lblk_end] and returns
- * whether there are any buffers marked for delayed allocation. It returns '1'
- * on the first delalloc'ed buffer head found. If no buffer head in the given
- * range is marked for delalloc, it returns 0.
- * lblk_start should always be <= lblk_end.
- * search_hint_reverse is to indicate that searching in reverse from lblk_end to
- * lblk_start might be more efficient (i.e., we will likely hit the delalloc'ed
- * block sooner). This is useful when blocks are truncated sequentially from
- * lblk_start towards lblk_end.
+ * Return 1 if there is a delalloc block in the range, otherwise 0.
*/
static int ext4_find_delalloc_range(struct inode *inode,
ext4_lblk_t lblk_start,
- ext4_lblk_t lblk_end,
- int search_hint_reverse)
+ ext4_lblk_t lblk_end)
{
- struct address_space *mapping = inode->i_mapping;
- struct buffer_head *head, *bh = NULL;
- struct page *page;
- ext4_lblk_t i, pg_lblk;
- pgoff_t index;
-
- /* reverse search wont work if fs block size is less than page size */
- if (inode->i_blkbits < PAGE_CACHE_SHIFT)
- search_hint_reverse = 0;
-
- if (search_hint_reverse)
- i = lblk_end;
- else
- i = lblk_start;
-
- index = i >> (PAGE_CACHE_SHIFT - inode->i_blkbits);
-
- while ((i >= lblk_start) && (i <= lblk_end)) {
- page = find_get_page(mapping, index);
- if (!page)
- goto nextpage;
-
- if (!page_has_buffers(page))
- goto nextpage;
-
- head = page_buffers(page);
- if (!head)
- goto nextpage;
-
- bh = head;
- pg_lblk = index << (PAGE_CACHE_SHIFT -
- inode->i_blkbits);
- do {
- if (unlikely(pg_lblk < lblk_start)) {
- /*
- * This is possible when fs block size is less
- * than page size and our cluster starts/ends in
- * middle of the page. So we need to skip the
- * initial few blocks till we reach the 'lblk'
- */
- pg_lblk++;
- continue;
- }
-
- /* Check if the buffer is delayed allocated and that it
- * is not yet mapped. (when da-buffers are mapped during
- * their writeout, their da_mapped bit is set.)
- */
- if (buffer_delay(bh) && !buffer_da_mapped(bh)) {
- page_cache_release(page);
- trace_ext4_find_delalloc_range(inode,
- lblk_start, lblk_end,
- search_hint_reverse,
- 1, i);
- return 1;
- }
- if (search_hint_reverse)
- i--;
- else
- i++;
- } while ((i >= lblk_start) && (i <= lblk_end) &&
- ((bh = bh->b_this_page) != head));
-nextpage:
- if (page)
- page_cache_release(page);
- /*
- * Move to next page. 'i' will be the first lblk in the next
- * page.
- */
- if (search_hint_reverse)
- index--;
- else
- index++;
- i = index << (PAGE_CACHE_SHIFT - inode->i_blkbits);
- }
+ struct delayed_extent de;
- trace_ext4_find_delalloc_range(inode, lblk_start, lblk_end,
- search_hint_reverse, 0, 0);
- return 0;
+ de.start = lblk_start;
+ ext4_de_find_extent(inode, &de);
+ return (de.start + de.len) >= lblk_end && de.start <= lblk_start;
}
-int ext4_find_delalloc_cluster(struct inode *inode, ext4_lblk_t lblk,
- int search_hint_reverse)
+int ext4_find_delalloc_cluster(struct inode *inode, ext4_lblk_t lblk)
{
struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
ext4_lblk_t lblk_start, lblk_end;
lblk_start = lblk & (~(sbi->s_cluster_ratio - 1));
lblk_end = lblk_start + sbi->s_cluster_ratio - 1;
- return ext4_find_delalloc_range(inode, lblk_start, lblk_end,
- search_hint_reverse);
+ return ext4_find_delalloc_range(inode, lblk_start, lblk_end);
}
/**
@@ -3426,7 +3341,7 @@ get_reserved_cluster_alloc(struct inode *inode, ext4_lblk_t lblk_start,
lblk_from = lblk_start & (~(sbi->s_cluster_ratio - 1));
lblk_to = lblk_from + c_offset - 1;
- if (ext4_find_delalloc_range(inode, lblk_from, lblk_to, 0))
+ if (ext4_find_delalloc_range(inode, lblk_from, lblk_to))
allocated_clusters--;
}
@@ -3436,7 +3351,7 @@ get_reserved_cluster_alloc(struct inode *inode, ext4_lblk_t lblk_start,
lblk_from = lblk_start + num_blks;
lblk_to = lblk_from + (sbi->s_cluster_ratio - c_offset) - 1;
- if (ext4_find_delalloc_range(inode, lblk_from, lblk_to, 0))
+ if (ext4_find_delalloc_range(inode, lblk_from, lblk_to))
allocated_clusters--;
}
@@ -3727,7 +3642,7 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
ext4_ext_in_cache(inode, map->m_lblk, &newex)) {
if (!newex.ee_start_lo && !newex.ee_start_hi) {
if ((sbi->s_cluster_ratio > 1) &&
- ext4_find_delalloc_cluster(inode, map->m_lblk, 0))
+ ext4_find_delalloc_cluster(inode, map->m_lblk))
map->m_flags |= EXT4_MAP_FROM_CLUSTER;
if ((flags & EXT4_GET_BLOCKS_CREATE) == 0) {
@@ -3903,7 +3818,7 @@ int ext4_ext_map_blocks(handle_t *handle, struct inode *inode,
}
if ((sbi->s_cluster_ratio > 1) &&
- ext4_find_delalloc_cluster(inode, map->m_lblk, 0))
+ ext4_find_delalloc_cluster(inode, map->m_lblk))
map->m_flags |= EXT4_MAP_FROM_CLUSTER;
/*
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index f573020..5ae0c0d 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -398,49 +398,6 @@ static pgoff_t ext4_num_dirty_pages(struct inode *inode, pgoff_t idx,
}
/*
- * Sets the BH_Da_Mapped bit on the buffer heads corresponding to the given map.
- */
-static void set_buffers_da_mapped(struct inode *inode,
- struct ext4_map_blocks *map)
-{
- struct address_space *mapping = inode->i_mapping;
- struct pagevec pvec;
- int i, nr_pages;
- pgoff_t index, end;
-
- index = map->m_lblk >> (PAGE_CACHE_SHIFT - inode->i_blkbits);
- end = (map->m_lblk + map->m_len - 1) >>
- (PAGE_CACHE_SHIFT - inode->i_blkbits);
-
- pagevec_init(&pvec, 0);
- while (index <= end) {
- nr_pages = pagevec_lookup(&pvec, mapping, index,
- min(end - index + 1,
- (pgoff_t)PAGEVEC_SIZE));
- if (nr_pages == 0)
- break;
- for (i = 0; i < nr_pages; i++) {
- struct page *page = pvec.pages[i];
- struct buffer_head *bh, *head;
-
- if (unlikely(page->mapping != mapping) ||
- !PageDirty(page))
- break;
-
- if (page_has_buffers(page)) {
- bh = head = page_buffers(page);
- do {
- set_buffer_da_mapped(bh);
- bh = bh->b_this_page;
- } while (bh != head);
- }
- index++;
- }
- pagevec_release(&pvec);
- }
-}
-
-/*
* The ext4_map_blocks() function tries to look up the requested blocks,
* and returns if the blocks are already mapped.
*
@@ -573,13 +530,8 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE) {
ext4_clear_inode_state(inode, EXT4_STATE_DELALLOC_RESERVED);
- /* If we have successfully mapped the delayed allocated blocks,
- * set the BH_Da_Mapped bit on them. Its important to do this
- * under the protection of i_data_sem.
- */
if (retval > 0 && map->m_flags & EXT4_MAP_MAPPED) {
int ret;
- set_buffers_da_mapped(inode, map);
delayed_mapped:
/* delayed allocation blocks has been allocated */
ret = ext4_de_remove_space(inode, map->m_lblk,
@@ -1227,7 +1179,6 @@ static void ext4_da_page_release_reservation(struct page *page,
if ((offset <= curr_off) && (buffer_delay(bh))) {
to_release++;
clear_buffer_delay(bh);
- clear_buffer_da_mapped(bh);
}
curr_off = next_off;
} while ((bh = bh->b_this_page) != head);
@@ -1240,7 +1191,7 @@ static void ext4_da_page_release_reservation(struct page *page,
lblk = (page->index << (PAGE_CACHE_SHIFT - inode->i_blkbits)) +
((num_clusters - 1) << sbi->s_cluster_bits);
if (sbi->s_cluster_ratio == 1 ||
- !ext4_find_delalloc_cluster(inode, lblk, 1))
+ !ext4_find_delalloc_cluster(inode, lblk))
ext4_da_release_space(inode, 1);
num_clusters--;
@@ -1346,8 +1297,6 @@ static int mpage_da_submit_io(struct mpage_da_data *mpd,
clear_buffer_delay(bh);
bh->b_blocknr = pblock;
}
- if (buffer_da_mapped(bh))
- clear_buffer_da_mapped(bh);
if (buffer_unwritten(bh) ||
buffer_mapped(bh))
BUG_ON(bh->b_blocknr != pblock);
--
1.7.5.1
^ permalink raw reply related
* [PATCH V3 5/6] ext4: reimplement fiemap on delayed extent tree
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4, Yongqiang Yang
In-Reply-To: <1320022547-2284-1-git-send-email-xiaoqiangnk@gmail.com>
This patch reimplements fiemap on delayed extent tree.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
---
fs/ext4/extents.c | 186 +++++++----------------------------------------------
1 files changed, 23 insertions(+), 163 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index f878da1..ad6f5af 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4457,193 +4457,53 @@ static int ext4_ext_fiemap_cb(struct inode *inode, ext4_lblk_t next,
struct ext4_ext_cache *newex, struct ext4_extent *ex,
void *data)
{
+ struct delayed_extent de;
__u64 logical;
__u64 physical;
__u64 length;
__u32 flags = 0;
+ ext4_lblk_t next_del;
int ret = 0;
struct fiemap_extent_info *fieinfo = data;
unsigned char blksize_bits;
- blksize_bits = inode->i_sb->s_blocksize_bits;
- logical = (__u64)newex->ec_block << blksize_bits;
+ de.start = newex->ec_block;
+ down_read(&EXT4_I(inode)->i_data_sem);
+ next_del = ext4_de_find_extent(inode, &de);
+ up_read(&EXT4_I(inode)->i_data_sem);
+ next = min(next_del, next);
if (newex->ec_start == 0) {
/*
* No extent in extent-tree contains block @newex->ec_start,
* then the block may stay in 1)a hole or 2)delayed-extent.
- *
- * Holes or delayed-extents are processed as follows.
- * 1. lookup dirty pages with specified range in pagecache.
- * If no page is got, then there is no delayed-extent and
- * return with EXT_CONTINUE.
- * 2. find the 1st mapped buffer,
- * 3. check if the mapped buffer is both in the request range
- * and a delayed buffer. If not, there is no delayed-extent,
- * then return.
- * 4. a delayed-extent is found, the extent will be collected.
*/
- ext4_lblk_t end = 0;
- pgoff_t last_offset;
- pgoff_t offset;
- pgoff_t index;
- pgoff_t start_index = 0;
- struct page **pages = NULL;
- struct buffer_head *bh = NULL;
- struct buffer_head *head = NULL;
- unsigned int nr_pages = PAGE_SIZE / sizeof(struct page *);
-
- pages = kmalloc(PAGE_SIZE, GFP_KERNEL);
- if (pages == NULL)
- return -ENOMEM;
-
- offset = logical >> PAGE_SHIFT;
-repeat:
- last_offset = offset;
- head = NULL;
- ret = find_get_pages_tag(inode->i_mapping, &offset,
- PAGECACHE_TAG_DIRTY, nr_pages, pages);
-
- if (!(flags & FIEMAP_EXTENT_DELALLOC)) {
- /* First time, try to find a mapped buffer. */
- if (ret == 0) {
-out:
- for (index = 0; index < ret; index++)
- page_cache_release(pages[index]);
- /* just a hole. */
- kfree(pages);
- return EXT_CONTINUE;
- }
- index = 0;
-
-next_page:
- /* Try to find the 1st mapped buffer. */
- end = ((__u64)pages[index]->index << PAGE_SHIFT) >>
- blksize_bits;
- if (!page_has_buffers(pages[index]))
- goto out;
- head = page_buffers(pages[index]);
- if (!head)
- goto out;
-
- index++;
- bh = head;
- do {
- if (end >= newex->ec_block +
- newex->ec_len)
- /* The buffer is out of
- * the request range.
- */
- goto out;
-
- if (buffer_mapped(bh) &&
- end >= newex->ec_block) {
- start_index = index - 1;
- /* get the 1st mapped buffer. */
- goto found_mapped_buffer;
- }
-
- bh = bh->b_this_page;
- end++;
- } while (bh != head);
-
- /* No mapped buffer in the range found in this page,
- * We need to look up next page.
- */
- if (index >= ret) {
- /* There is no page left, but we need to limit
- * newex->ec_len.
- */
- newex->ec_len = end - newex->ec_block;
- goto out;
- }
- goto next_page;
- } else {
- /*Find contiguous delayed buffers. */
- if (ret > 0 && pages[0]->index == last_offset)
- head = page_buffers(pages[0]);
- bh = head;
- index = 1;
- start_index = 0;
+ if (de.len == 0)
+ /* A hole found. */
+ return EXT_CONTINUE;
+
+ if (de.start > newex->ec_block) {
+ /* A hole found. */
+ newex->ec_len = min(de.start - newex->ec_block,
+ newex->ec_len);
+ return EXT_CONTINUE;
}
-found_mapped_buffer:
- if (bh != NULL && buffer_delay(bh)) {
- /* 1st or contiguous delayed buffer found. */
- if (!(flags & FIEMAP_EXTENT_DELALLOC)) {
- /*
- * 1st delayed buffer found, record
- * the start of extent.
- */
- flags |= FIEMAP_EXTENT_DELALLOC;
- newex->ec_block = end;
- logical = (__u64)end << blksize_bits;
- }
- /* Find contiguous delayed buffers. */
- do {
- if (!buffer_delay(bh))
- goto found_delayed_extent;
- bh = bh->b_this_page;
- end++;
- } while (bh != head);
-
- for (; index < ret; index++) {
- if (!page_has_buffers(pages[index])) {
- bh = NULL;
- break;
- }
- head = page_buffers(pages[index]);
- if (!head) {
- bh = NULL;
- break;
- }
-
- if (pages[index]->index !=
- pages[start_index]->index + index
- - start_index) {
- /* Blocks are not contiguous. */
- bh = NULL;
- break;
- }
- bh = head;
- do {
- if (!buffer_delay(bh))
- /* Delayed-extent ends. */
- goto found_delayed_extent;
- bh = bh->b_this_page;
- end++;
- } while (bh != head);
- }
- } else if (!(flags & FIEMAP_EXTENT_DELALLOC))
- /* a hole found. */
- goto out;
-
-found_delayed_extent:
- newex->ec_len = min(end - newex->ec_block,
- (ext4_lblk_t)EXT_INIT_MAX_LEN);
- if (ret == nr_pages && bh != NULL &&
- newex->ec_len < EXT_INIT_MAX_LEN &&
- buffer_delay(bh)) {
- /* Have not collected an extent and continue. */
- for (index = 0; index < ret; index++)
- page_cache_release(pages[index]);
- goto repeat;
- }
-
- for (index = 0; index < ret; index++)
- page_cache_release(pages[index]);
- kfree(pages);
+ flags |= FIEMAP_EXTENT_DELALLOC;
+ newex->ec_len = de.start + de.len - newex->ec_block;
}
- physical = (__u64)newex->ec_start << blksize_bits;
- length = (__u64)newex->ec_len << blksize_bits;
^ permalink raw reply related
* [PATCH V3 4/6] ext4: let ext4 maintian delayed extent trees
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4, Yongqiang Yang
In-Reply-To: <1320022547-2284-1-git-send-email-xiaoqiangnk@gmail.com>
This patch let ext4 maintain delayed extent trees.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
---
fs/ext4/extents.c | 2 ++
fs/ext4/indirect.c | 3 +++
fs/ext4/inode.c | 30 ++++++++++++++++++++++++++++--
fs/ext4/super.c | 12 +++++++++++-
4 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
index 37a5df7..f878da1 100644
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -4233,6 +4233,8 @@ void ext4_ext_truncate(struct inode *inode)
last_block = (inode->i_size + sb->s_blocksize - 1)
>> EXT4_BLOCK_SIZE_BITS(sb);
+ err = ext4_de_remove_space(inode, last_block,
+ EXT_MAX_BLOCKS - last_block);
err = ext4_ext_remove_space(inode, last_block);
/* In a multi-transaction truncate, we only make the final
diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
index 3cfc73f..f5f61b28 100644
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -22,6 +22,7 @@
#include <linux/module.h>
#include "ext4_jbd2.h"
+#include "ext4_extents.h"
#include "truncate.h"
#include <trace/events/ext4.h>
@@ -1399,6 +1400,8 @@ void ext4_ind_truncate(struct inode *inode)
down_write(&ei->i_data_sem);
ext4_discard_preallocations(inode);
+ ext4_de_remove_space(inode, last_block,
+ EXT_MAX_BLOCKS - last_block);
/*
* The orphan list entry will now protect us from any crash which
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index f97d671..f573020 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -486,7 +486,16 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
up_read((&EXT4_I(inode)->i_data_sem));
if (retval > 0 && map->m_flags & EXT4_MAP_MAPPED) {
- int ret = check_block_validity(inode, map);
+ int ret;
+ if (flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE) {
+ /* delayed alloc may be allocated by fallocate and
+ * coverted to initialized by directIO.
+ * we need to handle delayed extent here.
+ */
+ down_write((&EXT4_I(inode)->i_data_sem));
+ goto delayed_mapped;
+ }
+ ret = check_block_validity(inode, map);
if (ret != 0)
return ret;
}
@@ -568,8 +577,16 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode,
* set the BH_Da_Mapped bit on them. Its important to do this
* under the protection of i_data_sem.
*/
- if (retval > 0 && map->m_flags & EXT4_MAP_MAPPED)
+ if (retval > 0 && map->m_flags & EXT4_MAP_MAPPED) {
+ int ret;
set_buffers_da_mapped(inode, map);
+delayed_mapped:
+ /* delayed allocation blocks has been allocated */
+ ret = ext4_de_remove_space(inode, map->m_lblk,
+ map->m_len);
+ if (ret < 0)
+ retval = ret;
+ }
}
up_write((&EXT4_I(inode)->i_data_sem));
@@ -1676,6 +1693,7 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,
struct buffer_head *bh)
{
int retval;
+ int ret;
sector_t invalid_block = ~((sector_t) 0xffff);
if (invalid_block < ext4_blocks_count(EXT4_SB(inode->i_sb)->s_es))
@@ -1722,6 +1740,14 @@ static int ext4_da_map_blocks(struct inode *inode, sector_t iblock,
out_unlock:
up_read((&EXT4_I(inode)->i_data_sem));
+ if (retval ==0) {
+ down_write((&EXT4_I(inode)->i_data_sem));
+ ret = ext4_de_add_space(inode, map->m_lblk, map->m_len);
+ up_write((&EXT4_I(inode)->i_data_sem));
+ if (ret)
+ return ret;
+ }
+
return retval;
}
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 9515e5f..3df7c7b 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -50,6 +50,7 @@
#include "xattr.h"
#include "acl.h"
#include "mballoc.h"
+#include "ext4_extents.h"
#define CREATE_TRACE_POINTS
#include <trace/events/ext4.h>
@@ -984,6 +985,7 @@ void ext4_clear_inode(struct inode *inode)
end_writeback(inode);
dquot_drop(inode);
ext4_discard_preallocations(inode);
+ ext4_de_remove_space(inode, 0, EXT_MAX_BLOCKS);
if (EXT4_I(inode)->jinode) {
jbd2_journal_release_jbd_inode(EXT4_JOURNAL(inode),
EXT4_I(inode)->jinode);
@@ -5065,9 +5067,14 @@ static int __init ext4_init_fs(void)
init_waitqueue_head(&ext4__ioend_wq[i]);
}
- err = ext4_init_pageio();
+ err = ext4_init_de();
if (err)
return err;
+
+ err = ext4_init_pageio();
+ if (err)
+ goto out8;
+
err = ext4_init_system_zone();
if (err)
goto out6;
@@ -5117,6 +5124,9 @@ out5:
ext4_exit_system_zone();
out6:
ext4_exit_pageio();
+out8:
+ ext4_exit_de();
+
return err;
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH V3 3/6] ext4: initialize delayed extent tree
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4, Yongqiang Yang
In-Reply-To: <1320022547-2284-1-git-send-email-xiaoqiangnk@gmail.com>
Let ext4 initialize delayed extent tree of a inode.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
---
fs/ext4/super.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 9953d80..9515e5f 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -899,6 +899,7 @@ static struct inode *ext4_alloc_inode(struct super_block *sb)
memset(&ei->i_cached_extent, 0, sizeof(struct ext4_ext_cache));
INIT_LIST_HEAD(&ei->i_prealloc_list);
spin_lock_init(&ei->i_prealloc_lock);
+ ext4_de_init_tree(&ei->i_de_tree);
ei->i_reserved_data_blocks = 0;
ei->i_reserved_meta_blocks = 0;
ei->i_allocated_meta_blocks = 0;
--
1.7.5.1
^ permalink raw reply related
* [PATCH V3 2/6] ext4: add operations on delayed extent tree
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4, Yongqiang Yang
In-Reply-To: <1320022547-2284-1-git-send-email-xiaoqiangnk@gmail.com>
This patch adds operations on a delayed extent tree.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
---
fs/ext4/Makefile | 2 +-
fs/ext4/delayed_extents.c | 415 +++++++++++++++++++++++++++++++++++++++++++++
fs/ext4/delayed_extents.h | 18 ++
3 files changed, 434 insertions(+), 1 deletions(-)
create mode 100644 fs/ext4/delayed_extents.c
diff --git a/fs/ext4/Makefile b/fs/ext4/Makefile
index 56fd8f86..ee16ad3 100644
--- a/fs/ext4/Makefile
+++ b/fs/ext4/Makefile
@@ -7,7 +7,7 @@ obj-$(CONFIG_EXT4_FS) += ext4.o
ext4-y := balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o page-io.o \
ioctl.o namei.o super.o symlink.o hash.o resize.o extents.o \
ext4_jbd2.o migrate.o mballoc.o block_validity.o move_extent.o \
- mmp.o indirect.o
+ mmp.o indirect.o delayed_extents.o
ext4-$(CONFIG_EXT4_FS_XATTR) += xattr.o xattr_user.o xattr_trusted.o
ext4-$(CONFIG_EXT4_FS_POSIX_ACL) += acl.o
diff --git a/fs/ext4/delayed_extents.c b/fs/ext4/delayed_extents.c
new file mode 100644
index 0000000..899fc74
--- /dev/null
+++ b/fs/ext4/delayed_extents.c
@@ -0,0 +1,415 @@
+/*
+ * fs/ext4/delayed_extents.c
+ *
+ * Written by Yongqiang Yang <xiaoqiangnk@gmail.com>
+ *
+ * Ext4 delayed extents core functions.
+ */
+#include <linux/rbtree.h>
+#include "ext4.h"
+#include "delayed_extents.h"
+#include "ext4_extents.h"
+
+/*
+ * delayed extent implementation for ext4.
+ *
+ *
+ * ==========================================================================
+ * 1. Why delayed extent implementation ?
+ *
+ * Without delayed extent, ext4 identifies a delayed extent by looking up
+ * page cache, this has several deficiencies - complicated, buggy, and
+ * inefficient code.
+ *
+ * FIEMAP, SEEK_HOLE/DATA, bigalloc, punch hole and writeout all need to know if
+ * a block or a range of blocks are belonged to a delayed extent.
+ *
+ * Let us have a look at how they do without delayed extents implementation.
+ * -- FIEMAP
+ * FIEMAP looks up page cache to identify delayed allocations from holes.
+ *
+ * -- SEEK_HOLE/DATA
+ * SEEK_HOLE/DATA has the same problem as FIEMAP.
+ *
+ * -- bigalloc
+ * bigalloc looks up page cache to figure out if a block is already
+ * under delayed allocation or not to determine whether quota reserving
+ * is needed for the cluster.
+ *
+ * -- punch hole
+ * punch hole looks up page cache to identify a delayed extent.
+ *
+ * -- writeout
+ * Writeout looks up whole page cache to see if a buffer is mapped, If
+ * there are not very many delayed buffers, then it is time comsuming.
+ *
+ * With delayed extents implementation, FIEMAP, SEEK_HOLE/DATA, bigalloc and
+ * writeout can figure out if a block or a range of blocks is under delayed
+ * allocation(belonged to a delayed extent) or not by searching the delayed
+ * extent tree.
+ *
+ *
+ * ==========================================================================
+ * 2. ext4 delayed extents impelmentation
+ *
+ * -- delayed extent
+ * A delayed extent is a range of blocks which are contiguous logically and
+ * under delayed allocation. Unlike extent in ext4, delayed extent in ext4
+ * is a in-memory struct, there is no corresponding on-disk data. There is
+ * no limit on length of delayed extent, so a delayed extent can contain as
+ * many blocks as they are contiguous logically.
+ *
+ * -- delayed extent tree
+ * Every inode has a delayed extent tree and all under delayed allocation
+ * blocks are added to the tree as dealyed extents. Delayed extents in
+ * the tree are ordered by logical block no.
+ *
+ * -- operations on a delayed extent tree
+ * There are three operations on a delayed extent tree: find next delayed
+ * extent, adding a space(a range of blocks) and removing a space.
+ *
+ * -- race on a delayed extent tree
+ * Delayed extent tree is protected inode->i_data_sem like extent tree.
+ *
+ *
+ * ==========================================================================
+ * 3. performance analysis
+ * -- overhead
+ * 1. Apart from operations on a delayed extent tree, we need to
+ * down_write(inode->i_data_sem) in delayed write path to maintain delayed
+ * extent tree, this can have impact on parallel read-write and write-write
+ *
+ * 2. There is a cache extent for write access, so if writes are not very
+ * random, adding space operaions are in O(1) time.
+ *
+ * -- gain
+ * 3. Code is much simpler, more readable, more maintainable and
+ * more efficient.
+ */
+
+static struct kmem_cache *ext4_de_cachep;
+
+int __init ext4_init_de(void)
+{
+ ext4_de_cachep = KMEM_CACHE(delayed_extent, SLAB_RECLAIM_ACCOUNT);
+ if (ext4_de_cachep == NULL)
+ return -ENOMEM;
+ return 0;
+}
+
+void ext4_exit_de(void)
+{
+ if (ext4_de_cachep)
+ kmem_cache_destroy(ext4_de_cachep);
+}
+
+void ext4_de_init_tree(struct ext4_de_tree *tree)
+{
+ tree->root = RB_ROOT;
+ tree->cache_de = NULL;
+}
+
+#ifdef DE_DEBUG
+static void ext4_de_print_tree(struct inode *inode)
+{
+ struct ext4_de_tree *tree;
+ struct rb_node *node;
+
+ printk(KERN_DEBUG "delayed extents for inode %lu:", inode->i_ino);
+ tree = &EXT4_I(inode)->i_de_tree;
+ node = rb_first(&tree->root);
+ while(node) {
+ struct delayed_extent *de;
+ de = rb_entry(node, struct delayed_extent, rb_node);
+ printk(KERN_DEBUG " [%u/%u)", de->start, de->len);
+ node = rb_next(node);
+ }
+ printk(KERN_DEBUG "\n");
+}
+#else
+#define ext4_de_print_tree(inode)
+#endif
+
+static inline ext4_lblk_t delayed_extent_end(struct delayed_extent *de)
+{
+ if (de->start + de->len < de->start)
+ return (ext4_lblk_t)-1;
+ return de->start + de->len;
+}
+
+/*
+ * search through the tree for an delayed_extent with a given offset. If
+ * it can't be found, try to find next extent.
+ */
+static struct delayed_extent * __de_tree_search(struct rb_root *root,
+ ext4_lblk_t offset)
+{
+ struct rb_node *node = root->rb_node;
+ struct delayed_extent *de = NULL;
+
+ while (node) {
+ de = rb_entry(node, struct delayed_extent, rb_node);
+ if (offset < de->start)
+ node = node->rb_left;
+ else if (offset >= delayed_extent_end(de))
+ node = node->rb_right;
+ else
+ return de;
+ }
+
+ if (de && offset < de->start)
+ return de;
+
+ if (de && offset >= delayed_extent_end(de)) {
+ node = rb_next(&de->rb_node);
+ return node ? rb_entry(node, struct delayed_extent, rb_node) :
+ NULL;
+ }
+
+ return NULL;
+}
+
+/*
+ * ext4_de_find_extent: find the 1st delayed extent covering @de->start
+ * if it exists, otherwise, the next extent after @de->start.
+ *
+ * @inode: the inode which owns delayed extents
+ * @de:
+ *
+ * Returns next block beyond the found extent.
+ * Delayed extent is returned via @de.
+ */
+ext4_lblk_t ext4_de_find_extent(struct inode *inode, struct delayed_extent *de)
+{
+ struct ext4_de_tree *tree;
+ struct delayed_extent *de1;
+ struct rb_node *node;
+
+ de->len = 0;
+ tree = &EXT4_I(inode)->i_de_tree;
+ de1 = __de_tree_search(&tree->root, de->start);
+ if (de1) {
+ tree->cache_de = de1;
+ de->start = de1->start;
+ de->len = de1->len;
+ node = rb_next(&de1->rb_node);
+ if (node) {
+ de1 = rb_entry(node, struct delayed_extent, rb_node);
+ return de1->start;
+ }
+ }
+
+ return EXT_MAX_BLOCKS;
+}
+
+static struct delayed_extent *
+ext4_de_alloc_extent(ext4_lblk_t start, ext4_lblk_t len)
+{
+ struct delayed_extent *de;
+ de = kmem_cache_alloc(ext4_de_cachep, GFP_NOFS);
+ if (de == NULL)
+ return NULL;
+ de->start = start;
+ de->len = len;
+ return de;
+}
+
+static void ext4_de_free_extent(struct delayed_extent *de)
+{
+ kmem_cache_free(ext4_de_cachep, de);
+}
+
+static void ext4_de_try_to_merge_left(struct ext4_de_tree *tree,
+ struct delayed_extent *de)
+{
+ struct delayed_extent *de1;
+ struct rb_node *node;
+
+ node = rb_prev(&de->rb_node);
+ if (!node)
+ return;
+
+ de1 = rb_entry(node, struct delayed_extent, rb_node);
+ if (delayed_extent_end(de1) == de->start) {
+ de1->len += de->len;
+ rb_erase(&de->rb_node, &tree->root);
+ if (de == tree->cache_de)
+ tree->cache_de = de1;
+ ext4_de_free_extent(de);
+ }
+}
+
+static void ext4_de_try_to_merge_right(struct ext4_de_tree *tree,
+ struct delayed_extent *de)
+{
+ struct delayed_extent *de1;
+ struct rb_node *node;
+
+ node = rb_next(&de->rb_node);
+ if (!node)
+ return;
+
+ de1 = rb_entry(node, struct delayed_extent, rb_node);
+ if (de1->start == delayed_extent_end(de)) {
+ de->len += de1->len;
+ rb_erase(node, &tree->root);
+ if (de1 == tree->cache_de)
+ tree->cache_de = de;
+ ext4_de_free_extent(de1);
+ }
+}
+
+/*
+ * ext4_de_add_space: adds a space to a delayed extent tree.
+ * Caller holds inode->i_data_sem.
+ *
+ * ext4_de_add_space is callyed by ext4_dealyed_write_begin and
+ * ext4_de_remove_space.
+ *
+ * Return 0 on success, error code on failure.
+ */
+int ext4_de_add_space(struct inode *inode, ext4_lblk_t offset, ext4_lblk_t len)
+{
+ struct ext4_de_tree *tree = &EXT4_I(inode)->i_de_tree;
+ struct rb_node **p = &tree->root.rb_node;
+ struct rb_node *parent = NULL;
+ struct delayed_extent *de;
+ ext4_lblk_t end = offset + len;
+
+ BUG_ON(end <= offset);
+
+ de = tree->cache_de;
+ de_debug("add [%u/%u) to delayed extent tree of inode %lu\n",
+ offset, len, inode->i_ino);
+
+ if (de && delayed_extent_end(de) == offset) {
+ de_debug("cached by [%u/%u)\n", de->start, de->len);
+ de->len += len;
+ ext4_de_try_to_merge_right(tree, de);
+ goto out;
+ } else if (de && de->start == end) {
+ de_debug("cached by [%u/%u)\n", de->start, de->len);
+ de->start = offset;
+ de->len += len;
+ ext4_de_try_to_merge_left(tree, de);
+ goto out;
+ } else if (de && de->start <= offset &&
+ delayed_extent_end(de) >= end) {
+ de_debug("cached by [%u/%u)\n", de->start, de->len);
+ goto out;
+ }
+
+ while (*p) {
+ parent = *p;
+ de = rb_entry(parent, struct delayed_extent, rb_node);
+
+ if (offset < de->start) {
+ if (end == de->start) {
+ de->len += len;
+ de->start = offset;
+ goto out;
+ }
+ p = &(*p)->rb_left;
+ } else if (offset >= delayed_extent_end(de)) {
+ if (delayed_extent_end(de) == offset) {
+ de->len += len;
+ goto out;
+ }
+ p = &(*p)->rb_right;
+ } else
+ goto out;
+ }
+
+ de = ext4_de_alloc_extent(offset, len);
+ if (!de)
+ return -ENOMEM;
+ rb_link_node(&de->rb_node, parent, p);
+ rb_insert_color(&de->rb_node, &tree->root);
+
+out:
+ tree->cache_de = de;
+ ext4_de_print_tree(inode);
+
+ return 0;
+}
+
+/*
+ * ext4_de_remove_space() removes a space from a delayed extent tree.
+ * Caller holds inode->i_data_sem.
+ *
+ * Return 0 on success, error code on failure.
+ */
+int ext4_de_remove_space(struct inode *inode, ext4_lblk_t offset,
+ ext4_lblk_t len)
+{
+ struct rb_node *node;
+ struct ext4_de_tree *tree;
+ struct delayed_extent *de;
+ struct delayed_extent orig_de;
+ ext4_lblk_t len1, len2, end;
+
+ de_debug("remove [%u/%u) from delayed extent tree of inode %lu\n",
+ offset, len, inode->i_ino);
+
+ end = offset + len;
+ BUG_ON(end <= offset);
+ tree = &EXT4_I(inode)->i_de_tree;
+ de = __de_tree_search(&tree->root, offset);
+ if (!de)
+ goto out;
+
+ /* Simply invalidate cache_de. */
+ tree->cache_de = NULL;
+
+ orig_de.start = de->start;
+ orig_de.len = de->len;
+ len1 = offset > de->start ? offset - de->start : 0;
+ len2 = delayed_extent_end(de) > end ?
+ delayed_extent_end(de) - end : 0;
+ if (len1 > 0)
+ de->len = len1;
+ if (len2 > 0) {
+ if (len1 > 0) {
+ int err;
+ err = ext4_de_add_space(inode, end, len2);
+ if (err) {
+ de->start = orig_de.start;
+ de->len = orig_de.len;
+ return err;
+ }
+ } else {
+ de->start = end;
+ de->len = len2;
+ }
+ goto out;
+ }
+
+ if (len1 > 0) {
+ node = rb_next(&de->rb_node);
+ if (!node)
+ de = rb_entry(node, struct delayed_extent, rb_node);
+ else
+ de = NULL;
+ }
+
+ while (de && delayed_extent_end(de) <= end) {
+ node = rb_next(&de->rb_node);
+ rb_erase(&de->rb_node, &tree->root);
+ ext4_de_free_extent(de);
+ if (!node) {
+ de = NULL;
+ break;
+ }
+ de = rb_entry(node, struct delayed_extent, rb_node);
+ }
+
+ if (de && de->start < end) {
+ len1 = delayed_extent_end(de) - end;
+ de->start = end;
+ de->len = len1;
+ }
+
+out:
+ ext4_de_print_tree(inode);
+ return 0;
+}
diff --git a/fs/ext4/delayed_extents.h b/fs/ext4/delayed_extents.h
index 5436cad..cfd122e 100644
--- a/fs/ext4/delayed_extents.h
+++ b/fs/ext4/delayed_extents.h
@@ -8,6 +8,13 @@
#ifndef _EXT4_DELAYED_EXTENTS_H
#define _EXT4_DELAYED_EXTENTS_H
+#define DE_DEBUG
+#ifdef DE_DEBUG
+#define de_debug(a...) printk(a)
+#else
+#define de_debug(a...)
+#endif
+
struct delayed_extent {
struct rb_node rb_node;
ext4_lblk_t start; /* first block extent covers */
@@ -19,4 +26,15 @@ struct ext4_de_tree {
struct delayed_extent *cache_de; /* recently accessed extent */
};
+extern int __init ext4_init_de(void);
+extern void ext4_exit_de(void);
+extern void ext4_de_init_tree(struct ext4_de_tree *tree);
+
+extern int ext4_de_add_space(struct inode *inode, ext4_lblk_t start,
+ ext4_lblk_t len);
+extern int ext4_de_remove_space(struct inode *inode, ext4_lblk_t start,
+ ext4_lblk_t len);
+extern ext4_lblk_t ext4_de_find_extent(struct inode *inode,
+ struct delayed_extent *de);
+
#endif /* _EXT4_DELAYED_EXTENTS_H */
--
1.7.5.1
^ permalink raw reply related
* [PATCH V3 1/6] ext4: add two structures supporting delayed extent tree
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4, Yongqiang Yang
In-Reply-To: <1320022547-2284-1-git-send-email-xiaoqiangnk@gmail.com>
This patch adds two structures that supports delayed extent tree and
delayed_extent_info to inode_info.
Signed-off-by: Yongqiang Yang <xiaoqiangnk@gmail.com>
---
fs/ext4/delayed_extents.h | 22 ++++++++++++++++++++++
fs/ext4/ext4.h | 5 +++++
2 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 fs/ext4/delayed_extents.h
diff --git a/fs/ext4/delayed_extents.h b/fs/ext4/delayed_extents.h
new file mode 100644
index 0000000..5436cad
--- /dev/null
+++ b/fs/ext4/delayed_extents.h
@@ -0,0 +1,22 @@
+/*
+ * fs/ext4/delayed_extents.h
+ *
+ * Written by Yongqiang Yang <xiaoqiangnk@gmail.com>
+ *
+ */
+
+#ifndef _EXT4_DELAYED_EXTENTS_H
+#define _EXT4_DELAYED_EXTENTS_H
+
+struct delayed_extent {
+ struct rb_node rb_node;
+ ext4_lblk_t start; /* first block extent covers */
+ ext4_lblk_t len; /* length of extent in block */
+};
+
+struct ext4_de_tree {
+ struct rb_root root;
+ struct delayed_extent *cache_de; /* recently accessed extent */
+};
+
+#endif /* _EXT4_DELAYED_EXTENTS_H */
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 657e826..72c6b1e 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -778,6 +778,8 @@ struct ext4_ext_cache {
__u32 ec_len; /* must be 32bit to return holes */
};
+#include "delayed_extents.h"
+
/*
* fourth extended file system inode data in memory
*/
@@ -855,6 +857,9 @@ struct ext4_inode_info {
struct list_head i_prealloc_list;
spinlock_t i_prealloc_lock;
+ /* delayed extents */
+ struct ext4_de_tree i_de_tree;
+
/* ialloc */
ext4_group_t i_last_alloc_group;
--
1.7.5.1
^ permalink raw reply related
* [PATCH V3 0/6] ext4: add delayed extent tree for ext4
From: Yongqiang Yang @ 2011-10-31 0:55 UTC (permalink / raw)
To: tytso; +Cc: linux-ext4
Hi,
This patch series add delayed extent tree support for ext4. More
documentation please refer to fs/ext4/delayed_extents.c which is in
the 2nd patch.
V2->V3:
reimplement find_delay_alloc_range on delayed extent tree(PATCH 6).
V1->V2:
change list to rb tree.
git diff --stat
fs/ext4/Makefile | 2 +-
fs/ext4/delayed_extents.c | 415 +++++++++++++++++++++++++++++++++++++++++++++
fs/ext4/delayed_extents.h | 40 +++++
fs/ext4/ext4.h | 9 +-
fs/ext4/ext4_extents.h | 3 +-
fs/ext4/extents.c | 297 ++++----------------------------
fs/ext4/indirect.c | 3 +
fs/ext4/inode.c | 83 +++------
fs/ext4/super.c | 13 ++-
9 files changed, 543 insertions(+), 322 deletions(-)
[PATCH V3 1/6] ext4: add two structures supporting delayed extent
[PATCH V3 2/6] ext4: add operations on delayed extent tree
[PATCH V3 3/6] ext4: initialize delayed extent tree
[PATCH V3 4/6] ext4: let ext4 maintian delayed extent trees
[PATCH V3 5/6] ext4: reimplement fiemap on delayed extent tree
[PATCH V3 6/6] ext4: reimplement ext4_find_delay_alloc_range on
^ permalink raw reply
* When can a net device get its setting correctly ?
From: WeipingPan @ 2011-10-31 2:53 UTC (permalink / raw)
To: open list:NETWORKING [GENERAL]
Hi, all,
BUG DESCRIPTION:
Zheng Liang(lzheng@redhat.com) found a problem that if we config bonding
with arp monitor,
and enslave 10G cards, bonding driver cannot get the speed and duplex
from them,
it will assume to be 100Mb/sec and Full.
I test kernel upstream, commit ec7ae517537a(Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6),
it also has this problem.
And not only 10G cards have this problem, when I use 1Gb(igb), the
problem is the same.
[root@dell-p390n-01 ~]# uname -a
Linux dell-p390n-01.lab.bos.redhat.com 3.1.0+ #1 SMP Fri Oct 28 23:38:59
EDT 2011 i686 i686 i386 GNU/Linux
[root@dell-p390n-01 ~]# dmesg |grep p4p1
udev: renamed network interface eth0 to p4p1
ADDRCONF(NETDEV_UP): p4p1: link is not ready
igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
ADDRCONF(NETDEV_CHANGE): p4p1: link becomes ready
[root@dell-p390n-01 ~]# ethtool p4p1
Settings for p4p1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Current message level: 0x00000003 (3)
Link detected: yes
[root@dell-p390n-01 ~]# modprobe bonding mode=1 arp_interval=100
arp_ip_target=10.66.12.130
[root@dell-p390n-01 ~]# ifconfig bond0 up
[root@dell-p390n-01 ~]# ifenslave bond0 p4p1
[root@dell-p390n-01 ~]# dmesg
bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: ARP monitoring set to 100 ms, validate none, with 1 target(s):
bonding: 10.66.12.130
bonding:
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0: Warning: failed to get speed and duplex from p4p1,
assumed to be 100Mb/sec and Full.<-----bug
bonding: bond0: making interface p4p1 the new active one.
bonding: bond0: first active interface up!
bonding: bond0: enslaving p4p1 as an active interface with an up link.
ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
bonding: bond0: link status definitely down for interface p4p1, disabling it
bonding: bond0: now running without any active interface !
igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
[root@dell-p390n-01 ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: None
MII Status: down
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
ARP Polling Interval (ms): 100
ARP IP target/s (n.n.n.n form): 10.66.12.130
Slave Interface: p4p1
MII Status: down
Speed: 100 Mbps <------ bug
Duplex: full
Link Failure Count: 1
Permanent HW addr: 00:1b:21:66:d8:a0
Slave queue ID: 0
But there is no such problem when use miimon.
[root@dell-p390n-01 ~]# modprobe bonding mode=1 miimon=100
[root@dell-p390n-01 ~]# ifconfig bond0 up
[root@dell-p390n-01 ~]# ifenslave bond0 p4p1
[root@dell-p390n-01 ~]# dmesg
bonding: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
bonding: MII link monitoring set to 100 ms
ADDRCONF(NETDEV_UP): bond0: link is not ready
bonding: bond0: enslaving p4p1 as a backup interface with a down link.
igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
bonding: bond0: link status definitely up for interface p4p1, 1000 Mbps
full duplex.
bonding: bond0: making interface p4p1 the new active one.
bonding: bond0: first active interface up!
ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
BUG ANALYSIS:
First, when uses arp monitor, the call trace is:
1485 int bond_enslave(struct net_device *bond_dev, struct net_device
*slave_dev)
1652 res = dev_open(slave_dev);
1761 if (bond_update_speed_duplex(new_slave) &&
And when calling bond_update_speed_duplex(), this message, "igb: p4p1
NIC Link
is Up 1000 Mbps Full Duplex, Flow Control: RX", doesn't show up.
So I think even we call dev_open(), but the device is not ready to get its
setting.
Second, when uses miimon, the call trace is:
1485 int bond_enslave(struct net_device *bond_dev, struct net_device
*slave_dev)
1652 res = dev_open(slave_dev);
2419 static void bond_miimon_commit(struct bonding *bond)
2444 bond_update_speed_duplex(slave);
And when calling bond_update_speed_duplex(), it gets correct setting.
QUESTION:
When can a net device get its setting correctly ?
Maybe dev_open() is not enough.
thanks
Weiping Pan
^ permalink raw reply
* Re: [Xenomai-help] which skin to use
From: Thomas Lockhart @ 2011-10-31 2:38 UTC (permalink / raw)
To: Łukasz Sacha; +Cc: xenomai@xenomai.org
In-Reply-To: <CAAeYjMmJ_LKimbvRsR5562MaYvrQGJkSx9jeP2RM3FQvewtg5Q@mail.gmail.com>
On 10/30/2011 03:47 PM, Łukasz Sacha wrote:
> Hi,
> I'm working on a device that will process several input signals (2
> analog, about 4 digital and 1 over serial interface) do some
> calculations and control 4 uarts. It will also write some log data to
> a file on an sd card.
> It will probably be a single process working in an infinite loop,
> regularly, say 50 times per second or more.
> I'm a total beginner as it comes to RT and xenomai. I have some
> experience in wrinting programs in C/C++ for linux.
> Which API should do you think will be good for me to start with?
> Which would be better for the application that I want to write?
I'd use the native API (others may have other advice, and I'd listen to
them if so). If you write your program using regular Linux threads, then
you can just add a few calls to convert the threads you need to be RT in
userland.
At 50Hz you might be able to get by with the regular Linux version,
unless you have very tight lag and jitter requirements. If you are going
for kHz then afaicr Linux will just not be able to schedule your tasks.
You can write your code, do initial testing, then add some #ifdef
XENOMAI lines to guard the extra Xenomai calls.
hth
- Tom
^ permalink raw reply
* Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8
From: Zhi Yong Wu @ 2011-10-31 2:38 UTC (permalink / raw)
To: Lucas Meneghel Rodrigues
Cc: Kevin Wolf, KVM mailing list, Stefan Hajnoczi, Marcelo Tosatti,
QEMU devel, Avi Kivity, Cleber Rosa, Richard Henderson
In-Reply-To: <4EAA9619.7060608@redhat.com>
On Fri, Oct 28, 2011 at 7:46 PM, Lucas Meneghel Rodrigues
<lmr@redhat.com> wrote:
> On 10/27/2011 11:17 PM, Zhi Yong Wu wrote:
>>
>> On Fri, Oct 28, 2011 at 2:57 AM, Lucas Meneghel Rodrigues
>> <lmr@redhat.com> wrote:
>>>
>>> On 10/27/2011 05:17 AM, Stefan Hajnoczi wrote:
>>>>
>>>> On Wed, Oct 26, 2011 at 03:19:17PM -0200, Lucas Meneghel Rodrigues
>>>> wrote:
>>>>>
>>>>> On 10/26/2011 01:47 PM, Kevin Wolf wrote:
>>>>>>
>>>>>> Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues:
>>>>>>>
>>>>>>> Hi folks:
>>>>>>>
>>>>>>> We've captured a regression with floppy disk on recent qemu (and
>>>>>>> qemu-kvm, after a code merge). We bisected it to be caused by:
>>>>>>>
>>>>>>> commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
>>>>>>> Author: Richard Henderson<rth@twiddle.net>
>>>>>>> Date: Mon Aug 15 15:08:45 2011 -0700
>>>>>>>
>>>>>>> fdc: Convert to isa_register_portio_list
>>>>>>>
>>>>>>> Signed-off-by: Richard Henderson<rth@twiddle.net>
>>>>>>> Signed-off-by: Avi Kivity<avi@redhat.com>
>>>>>>>
>>>>>>> Since this commit, the guest doesn't see a floppy disk attached to it
>>>>>>> anymore, blocking kvm autotest ability to install windows guests
>>>>>>> automatically. This is a big deal for kvm autotest (ruins our
>>>>>>> automated
>>>>>>> regression jobs), so please take a look at it.
>>>>>>
>>>>>> Can you please try again with the latest block branch? I think there
>>>>>> is
>>>>>> a patch queued that will fix it.
>>>>>
>>>>> Kevin, I did try with HEAD of your repo:
>>>>>
>>>>> git://repo.or.cz/qemu/kevin.git
>>>>>
>>>>> [lmr@freedom qemu-kwolf]$ git branch -r
>>>>> origin/HEAD -> origin/master
>>>>> origin/blkqueue
>>>>> origin/blkqueue-v1
>>>>> origin/block
>>>>> origin/coroutine
>>>>> origin/coroutine-block
>>>>> origin/coroutine-devel
>>>>> origin/devel
>>>>> origin/ehci
>>>>> origin/for-anthony
>>>>> origin/for-stable-0.14
>>>>> origin/inplace-conversion
>>>>> origin/master
>>>>>
>>>>> With this repo, master branch, the problem persists. With the block
>>>>> branch, the problem persists.
>>>>>
>>>>> Now, with the blkqueue branch the problem is resolved. Cleber had
>>>>> the same results booting a FreeDOS floppy. So the fix is indeed in
>>>>> blkqueue.
>>>>>
>>>>> Oh, you might want to check the blkqueue branch, it does have quite
>>>>> a bunch of set but unused variables, which will cause compilation
>>>>> errors unless --disable-werror is passed to the configure script.
>>>>
>>>> I think blkqueue is an older development branch of the "block queue"
>>>> feature that Kevin was working on. It is not Kevin's block tree (see
>>>> his "block" branch).
>>>
>>> So no, the block branch does not resolve the floppy access problem.
>>>
>>> Well, considering the tests of the stable set I'm running against qemu
>>> right
>>> now, this is not the biggest of our problems... I'm verifying qemu is
>>> segfaulting on nearly every prolonged attempt of doing migration... I'm
>>> about to write an email about it.
>>
>> What is the OS of your guest? fedora16 or RHEL6? I would like recently
>> to use floppy device in guest.
>
> Ok, correcting my answer, it was Windows 7 SP1. For some reason, I read
> 'host' instead of guest. I had a long day when I wrote the 1st reply.
>
> It's been a while that we've verified that the linux floppy driver is quite
> unstable. In general linux + floppy devices on a guest tends to crash the
> guest kernel, and that's why in kvm autotest we moved from floppy devices to
> cdroms to hold the kickstart file. The fact you managed to get things
> working under F14 means you are lucky, and that particular floppy driver bug
> does not happen under F14's kernel. We never had such a kernel crash problem
> with any of the Windows's kernels.
>
> So if I were you, I would *not* use a floppy with a linux guest. Well,
> unless you want to debug the floppy driver bug and fix this on upstream
> linux once for all, so future versions of linux won't have this problem.
I need to do some works for fdc, etc. So i have to use it in one
linux guest. anyway, thanks.
>
--
Regards,
Zhi Yong Wu
^ permalink raw reply
* Re: [Qemu-devel] qemu/qemu-kvm floppy regression brought by 212ec7baa28cc9d819234fed1541fc1423cfe3d8
From: Zhi Yong Wu @ 2011-10-31 2:38 UTC (permalink / raw)
To: Lucas Meneghel Rodrigues
Cc: Stefan Hajnoczi, Kevin Wolf, KVM mailing list, Marcelo Tosatti,
QEMU devel, Avi Kivity, Cleber Rosa, Richard Henderson
In-Reply-To: <4EAA9619.7060608@redhat.com>
On Fri, Oct 28, 2011 at 7:46 PM, Lucas Meneghel Rodrigues
<lmr@redhat.com> wrote:
> On 10/27/2011 11:17 PM, Zhi Yong Wu wrote:
>>
>> On Fri, Oct 28, 2011 at 2:57 AM, Lucas Meneghel Rodrigues
>> <lmr@redhat.com> wrote:
>>>
>>> On 10/27/2011 05:17 AM, Stefan Hajnoczi wrote:
>>>>
>>>> On Wed, Oct 26, 2011 at 03:19:17PM -0200, Lucas Meneghel Rodrigues
>>>> wrote:
>>>>>
>>>>> On 10/26/2011 01:47 PM, Kevin Wolf wrote:
>>>>>>
>>>>>> Am 26.10.2011 16:41, schrieb Lucas Meneghel Rodrigues:
>>>>>>>
>>>>>>> Hi folks:
>>>>>>>
>>>>>>> We've captured a regression with floppy disk on recent qemu (and
>>>>>>> qemu-kvm, after a code merge). We bisected it to be caused by:
>>>>>>>
>>>>>>> commit 212ec7baa28cc9d819234fed1541fc1423cfe3d8
>>>>>>> Author: Richard Henderson<rth@twiddle.net>
>>>>>>> Date: Mon Aug 15 15:08:45 2011 -0700
>>>>>>>
>>>>>>> fdc: Convert to isa_register_portio_list
>>>>>>>
>>>>>>> Signed-off-by: Richard Henderson<rth@twiddle.net>
>>>>>>> Signed-off-by: Avi Kivity<avi@redhat.com>
>>>>>>>
>>>>>>> Since this commit, the guest doesn't see a floppy disk attached to it
>>>>>>> anymore, blocking kvm autotest ability to install windows guests
>>>>>>> automatically. This is a big deal for kvm autotest (ruins our
>>>>>>> automated
>>>>>>> regression jobs), so please take a look at it.
>>>>>>
>>>>>> Can you please try again with the latest block branch? I think there
>>>>>> is
>>>>>> a patch queued that will fix it.
>>>>>
>>>>> Kevin, I did try with HEAD of your repo:
>>>>>
>>>>> git://repo.or.cz/qemu/kevin.git
>>>>>
>>>>> [lmr@freedom qemu-kwolf]$ git branch -r
>>>>> origin/HEAD -> origin/master
>>>>> origin/blkqueue
>>>>> origin/blkqueue-v1
>>>>> origin/block
>>>>> origin/coroutine
>>>>> origin/coroutine-block
>>>>> origin/coroutine-devel
>>>>> origin/devel
>>>>> origin/ehci
>>>>> origin/for-anthony
>>>>> origin/for-stable-0.14
>>>>> origin/inplace-conversion
>>>>> origin/master
>>>>>
>>>>> With this repo, master branch, the problem persists. With the block
>>>>> branch, the problem persists.
>>>>>
>>>>> Now, with the blkqueue branch the problem is resolved. Cleber had
>>>>> the same results booting a FreeDOS floppy. So the fix is indeed in
>>>>> blkqueue.
>>>>>
>>>>> Oh, you might want to check the blkqueue branch, it does have quite
>>>>> a bunch of set but unused variables, which will cause compilation
>>>>> errors unless --disable-werror is passed to the configure script.
>>>>
>>>> I think blkqueue is an older development branch of the "block queue"
>>>> feature that Kevin was working on. It is not Kevin's block tree (see
>>>> his "block" branch).
>>>
>>> So no, the block branch does not resolve the floppy access problem.
>>>
>>> Well, considering the tests of the stable set I'm running against qemu
>>> right
>>> now, this is not the biggest of our problems... I'm verifying qemu is
>>> segfaulting on nearly every prolonged attempt of doing migration... I'm
>>> about to write an email about it.
>>
>> What is the OS of your guest? fedora16 or RHEL6? I would like recently
>> to use floppy device in guest.
>
> Ok, correcting my answer, it was Windows 7 SP1. For some reason, I read
> 'host' instead of guest. I had a long day when I wrote the 1st reply.
>
> It's been a while that we've verified that the linux floppy driver is quite
> unstable. In general linux + floppy devices on a guest tends to crash the
> guest kernel, and that's why in kvm autotest we moved from floppy devices to
> cdroms to hold the kickstart file. The fact you managed to get things
> working under F14 means you are lucky, and that particular floppy driver bug
> does not happen under F14's kernel. We never had such a kernel crash problem
> with any of the Windows's kernels.
>
> So if I were you, I would *not* use a floppy with a linux guest. Well,
> unless you want to debug the floppy driver bug and fix this on upstream
> linux once for all, so future versions of linux won't have this problem.
I need to do some works for fdc, etc. So i have to use it in one
linux guest. anyway, thanks.
>
--
Regards,
Zhi Yong Wu
^ permalink raw reply
* [U-Boot] [PATCH] sh: fix build error in cache.h
From: Yoshihiro Shimoda @ 2011-10-31 2:35 UTC (permalink / raw)
To: u-boot
In-Reply-To: <201110302225.35809.vapier@gentoo.org>
2011/10/31 11:25, Mike Frysinger wrote:
> On Sunday 30 October 2011 21:44:13 Yoshihiro Shimoda wrote:
>> In the latest U-Boot, the include/common.h includes the asm/cache.h.
>> So, the dcache_invalid_range() in the arch/sh/include/asm/cache.h is
>> multiple defination.
>
> i posted a fix for this already:
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/114290
>
> i don't think we want to go this route with inline markings since it bloats
> the code ...
Thank you for your point.
I should have looked at the mailing list more carefully before I submitted
my patch...
Thanks,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH v2] drm/i915: Fix recursive calls to unmap
From: Keith Packard @ 2011-10-31 2:35 UTC (permalink / raw)
To: Ben Widawsky; +Cc: intel-gfx
In-Reply-To: <20111030185210.6d3a74d4@bwidawsk.net>
[-- Attachment #1.1: Type: text/plain, Size: 631 bytes --]
On Sun, 30 Oct 2011 18:52:10 -0700, Ben Widawsky <ben@bwidawsk.net> wrote:
> Well, I had to pick one, and looking at the call chain, it seemed there wasn't
> much to gain by doing retiring at this point.
The point is that you're mixing the stuff the commit message talks about
with other changes *which are not mentioned in the commit message* and
which are *unrelated to the bug in question*.
Two changes get two patches, it's pretty simple. And, commit messages
must tell the whole truth and nothing but the truth. I really hate
having to be this careful in reviewing your patches.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH] mfd: Add missed free_irq in da903x_remove
From: Axel Lin @ 2011-10-31 2:34 UTC (permalink / raw)
To: linux-kernel; +Cc: Mike Rapoport, Eric Miao, Samuel Ortiz
Signed-off-by: Axel Lin <axel.lin@gmail.com>
---
drivers/mfd/da903x.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/mfd/da903x.c b/drivers/mfd/da903x.c
index 1b79c37..62ce685 100644
--- a/drivers/mfd/da903x.c
+++ b/drivers/mfd/da903x.c
@@ -549,6 +549,7 @@ static int __devexit da903x_remove(struct i2c_client *client)
struct da903x_chip *chip = i2c_get_clientdata(client);
da903x_remove_subdevs(chip);
+ free_irq(client->irq, chip);
kfree(chip);
return 0;
}
--
1.7.5.4
^ permalink raw reply related
* [Qemu-devel] buildbot failure in qemu on default_x86_64_fedora16
From: qemu @ 2011-10-31 3:00 UTC (permalink / raw)
To: agraf, gollub, lcapitulino, qemu-devel
The Buildbot has detected a new failure on builder default_x86_64_fedora16 while building qemu.
Full details are available at:
http://buildbot.b1-systems.de/qemu/builders/default_x86_64_fedora16/builds/71
Buildbot URL: http://buildbot.b1-systems.de/qemu/
Buildslave for this Build: kraxel_fedora16
Build Reason: The Nightly scheduler named 'nightly_default' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist:
BUILD FAILED: failed git
sincerely,
-The Buildbot
^ permalink raw reply
* Business Proposal
From: Mr.Wang Shu @ 2011-10-31 2:29 UTC (permalink / raw)
This is Mr. Wang Shu from Hong Kong. I am sending you this message concerning a Business Proposal of $6,500,000.00
and I want you to partner with me in this project. This business will benefit you a lot. Please contact me back with the below
address for details:
Email: 673081wh@w.cn
I await your prompt response.
Thanks.
Mr. Wang Shu
^ permalink raw reply
* New Feature wanted: Is it possible to let git clone continue last break point?
From: netroby @ 2011-10-31 2:28 UTC (permalink / raw)
To: Git Mail List
In-Reply-To: <CAEZo+gfKVY-YgMjd=bEYzRV4-460kqDik-yVcQ9Xs=DoCZOMDg@mail.gmail.com>
Is it possible to let git clone continue last break point.
when we git clone very large project from the web, we may face some
interupt, then we must clone it from zero .
it is bad feeling for low connection speed users.
please help us out.
we need git clone continue last break point
netroby
----------------------------------
http://www.netroby.com
^ permalink raw reply
* [U-Boot] [PATCH] sh: fix build error in cache.h
From: Mike Frysinger @ 2011-10-31 2:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EADFD6C.4070502@renesas.com>
On Sunday 30 October 2011 21:44:13 Yoshihiro Shimoda wrote:
> In the latest U-Boot, the include/common.h includes the asm/cache.h.
> So, the dcache_invalid_range() in the arch/sh/include/asm/cache.h is
> multiple defination.
i posted a fix for this already:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/114290
i don't think we want to go this route with inline markings since it bloats
the code ...
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20111030/7a3f90d2/attachment.pgp
^ permalink raw reply
* [U-Boot] [PATCH V5 3/4] font: split font data from video_font.h
From: Che-liang Chiou @ 2011-10-31 2:23 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20111030193350.3c0ee033@wker>
Hi,
On Mon, Oct 31, 2011 at 2:33 AM, Anatolij Gustschin <agust@denx.de> wrote:
> Please next time additionally use '-C' Option for 'git format-patch ...'
Thanks for the advice. I will add -C option.
Regards,
Che-Liang
^ permalink raw reply
* Re: What is the strategy to update eglibc?
From: Kang Kai @ 2011-10-31 2:16 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Saul Wold
In-Reply-To: <4EAE0428.2020209@windriver.com>
On 2011年10月31日 10:12, Kang Kai wrote:
> Hi Saul,
>
> I just want to update eglibc but eglibc is using its 2.14 branch and
> use svn commit revision "15225" as current version. Of course it is
> behind the latest svn revision, but I don't quit sure about which is
> the right revision to update eglibc.
Hi Saul,
And right now is 2 commits behind the latest revision, do it worth to
update right now?
Thanks!
>
> Could you give me some guide? Thank you!
>
> Regards,
> Kai
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.