Re: 2.6.25-rc[1,2]: failed to setup dm-crypt key mapping
On Fri, Feb 22, 2008 at 08:34:23PM +0800, Herbert Xu wrote: > Does this patch fix the problem? It does fix the problem on my system. Jan -- 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: [preview] Latest AMD & VIA IDE drivers with UDMA100 support
On Sun, Jan 21, 2001 at 10:46:06AM +0100, Vojtech Pavlik wrote: > Ok, the VIA driver from clean 2.2.18 does nothing. It doesn't even use > hardcoded timings. It doesn't touch any timing tables. It just blindly > enables prefetch and writeback in the chips. The thing works because it > relies on BIOS to set things up correctly, and this is often the case, > yes. If BIOS is often correct: Is it possible to read these values and compare them to the values linux calculates? If both match: OK, continue. If they are different: Either BIOS or linux is wrong, print a warning and disable DMA (or go to some other kind of 'safe mode'). Just an idea, I don't know anything about chipsets and IDE timings ;-) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Error in x86 CPU capabilities starting with test5/6
On Fri, Nov 17, 2000 at 01:04:18PM +0100, Andi Kleen wrote: > The program would be broken if it executed CPUID itself, because it has no way to >guarantee > that the CPUID is executed on all CPUs the scheduler may later move the task too. I wonder what's the right way for an app to ask the kernel if, for example, tsc is available. As you stated above, executing CPUID is probably wrong. But if the process parses /proc/cpuinfo, it has to make sure tsc is available on all cpus it may run on, doesn't it? What about some system call stating 'I want to use feature XYZ'. If all CPUs implement XYZ, the system call simply returns some ACK, and NACK if no CPU implements it (and no emulation is available). If only some CPUs implement the feature, the kernel may return NACK, or it may make sure the process will only run on CPUs implementing the feature and return ACK. Is this usefull? It's just an idea ;-) I wonder if there are many features that may be available only on some CPUs in an 'SMP' system. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
fs corruption with invalidate_buffers()
Some days ago I saw filesystem corruptions while testing the ext2fs online resize patches by Andreas Dilger. First I thought that the online resizing caused the problems, but further investigations didn't support this. The latest observation shows that the problem is probably neither ext2 nor lvm related: While resizing the filesystem, invalidate_buffers() is called from the lvm code. (lvm.c, line 2251, in lvm_do_lv_extend_reduce()) If I remove this call, the corruption goes away. But this is probably not the correct fix, as it can cause problems when reducing the lv size. For reference, some details of the corruption: - I reproduced it with kernels between 2.4.0-test9 and 2.4.0-test12-pre5 - It is easily reproducible immediately after rebooting, but goes away after some uptime (perhaps simply related to the amount of unused memory) - example script follows (attention: absolute device names like /dev/vg1/test3 hardcoded!) --- #!/bin/bash umount /dev/vg1/test3 lvremove -f /dev/vg1/test3 lvcreate -n test3 -L 100M vg1 mke2fs -b 1024 /dev/vg1/test3 ext2prepare -v /dev/vg1/test3 50G mount /dev/vg1/test3 /mnt/test3 ( sleep 20; echo resize1; e2fsadm -L+90M /dev/vg1/test3; echo resize1 done ; sleep 10; echo resize2; e2fsadm -L+90M /dev/vg1/test3; echo resize2 done ) & echo copy1 cp -a /mnt/test/linux /mnt/test3/linux echo copy1 done echo copy2 cp -a /mnt/test3/linux /mnt/test3/linux2 echo copy2 done --- /mnt/test/linux contains (surprise) a linux source, but I don't think the contents are too important :-). The sleep values are tuned in a way that leads to the following sequence: copy1, resize1, resize1 done, copy1 done, copy2, resize2, resize2 done, copy2 done After that, the first copy is corrupted in memory only (and is ok after rebooting), and the second copy is corrupted in memory and on disk. The corrupted files contain parts of other files or binary stuff that may come from directory entries. I guess that invalidate_buffers somehow marks the buffers that contain the first copy as free, but the second cp still uses them to copy the files again. I don't understand the source well enough to find out how it happens. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Trashing ext2 with hdparm
On Wed, Dec 06, 2000 at 06:25:15PM +0100, Udo A. Steinberg wrote: > hdparm -tT /dev/hdb1 does the trick here. > > After that, several files are corrupted, such as /etc/mtab. > Reboot+fsck fixes the problem, however e2fsck never finds > any errors in the fs on disk. I'm currently trying to isolate a bug that is triggered by invalidate_buffers and leads to in-memory filesystem corruption. As hdparm -tT AFAIK calls invalidate_buffers (through BLKFLSBUF), this may be related. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Trashing ext2 with hdparm
On Wed, Dec 06, 2000 at 11:41:51AM -0800, Andre Hedrick wrote: > No way that this could cause corruption it is a read-only test. It definitely does, I saw it, too. It seems to be triggered by invalidate_buffers(). Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
attempt to access beyond end of device
ll_rw_blk.c: generic_make_request() contains the following code:
if (maxsector < count || maxsector - count < sector) {
bh->b_state &= (1 << BH_Lock) | (1 << BH_Mapped);
if (blk_size[major][MINOR(bh->b_rdev)]) {
/* This may well happen - the kernel calls bread()
without checking the size of the device, e.g.,
when mounting a device. */
printk(KERN_INFO
"attempt to access beyond end of device\n");
printk(KERN_INFO "%s: rw=%d, want=%d, limit=%d\n",
kdevname(bh->b_rdev), rw,
(sector + count)>>1,
blk_size[major][MINOR(bh->b_rdev)]);
}
bh->b_end_io(bh, 0);
return;
}
That means that if blk_size[major][MINOR(bh->b_rdev)] == 0, the request
is canceled but no message is printed. Shouldn't there be a warning message?
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: fs corruption with invalidate_buffers()
On Wed, Dec 06, 2000 at 03:07:23AM +0100, Jan Niehusmann wrote:
> While resizing the filesystem, invalidate_buffers() is called from the
> lvm code. (lvm.c, line 2251, in lvm_do_lv_extend_reduce())
> If I remove this call, the corruption goes away. But this is probably not
> the correct fix, as it can cause problems when reducing the lv size.
Some more details:
I added the following code to put_last_free(bh) in buffer.c:
--- buffer.c.orig Wed Dec 6 17:19:57 2000
+++ buffer.cThu Dec 7 19:55:39 2000
@@ -500,6 +500,11 @@
struct bh_free_head *head = &free_list[BUFSIZE_INDEX(bh->b_size)];
struct buffer_head **bhp = &head->list;
+ if(bh->b_page && Page_Uptodate(bh->b_page)
+ && bh->b_page->mapping) { // XXX ???
+ BUG();
+ }
+
bh->b_state = 0;
spin_lock(&head->lock);
That is, if I want to put a buffer to the free list, I check if it is
mapped and uptodate. If I understand the memory management correctly, this
is a Bad Thing and should not happen. But guess what? It does, in
invalidate_buffers.
I think invalidate_buffers should check if the buffer belongs to a
mapped page, and if it does, invalidate this mapping.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: fs corruption with invalidate_buffers()
The following patch actually prevents the corruption I described.
I'd like to hear from the people having problems with hdparm, if it helps
them, too.
Please note that the patch circumvents the problem more than it fixes it.
The true fix would invalidate the mappings, but I don't know how to do it.
Jan
--- linux-2.4.0-test11/fs/buffer.c Mon Nov 20 08:55:05 2000
+++ test/fs/buffer.cThu Dec 7 22:28:24 2000
@@ -589,7 +589,7 @@
then an invalidate_buffers call that doesn't trash dirty buffers. */
void __invalidate_buffers(kdev_t dev, int destroy_dirty_buffers)
{
- int i, nlist, slept;
+ int i, nlist, slept, db_message=0;
struct buffer_head * bh, * bh_next;
retry:
@@ -615,8 +615,13 @@
write_lock(&hash_table_lock);
if (!atomic_read(&bh->b_count) &&
(destroy_dirty_buffers || !buffer_dirty(bh))) {
- __remove_from_queues(bh);
- put_last_free(bh);
+ if(bh->b_page
+ && bh->b_page->mapping) {
+ db_message=1;
+ } else {
+ __remove_from_queues(bh);
+ put_last_free(bh);
+ }
}
/* else complain loudly? */
@@ -629,6 +634,8 @@
spin_unlock(&lru_list_lock);
if (slept)
goto retry;
+ if(db_message)
+ printk("invalidate_buffer with mapped page\n");
}
void set_blocksize(kdev_t dev, int size)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test5 problems with Promise ATA100
On Wed, Aug 30, 2000 at 12:05:02AM -0400, root wrote: > After compliation with the Promise UDMA chipsets support, with Use DMA > by Default checked, the kernel refuses to acknowledge the existence of > the chip. I have an ASUS K7M m/b that has the controller built in to > the motherboard. After using dmesg I saw no attempts at all to use the > kernel driver at all, no error message, etc. Any ideas? The german computer magazine c't had a review of the Asus A7V board with a Promise ATA100 controller in it's 18/2000 issue. They write: "Nutzer von BeOS oder Linux können den Chip derzeit nicht nutzen" (BeOS or Linux users can't use the chip at present) I'll CC: this mail tho the article's author, perhaps he can tell us more. The onboard Promise controller may contain a different chip than the Promise PCI cards, or it may need a special initialisation. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Scsi disks duplicated
With linux-2.4.0-test8, all my scsi disks appear duplicated: Detected scsi disk sda at scsi0, channel 0, id 3, lun 0 [...] Detected scsi disk sdb at scsi0, channel 0, id 4, lun 0 [...] Detected scsi disk sdc at scsi0, channel 0, id 3, lun 0 [...] Detected scsi disk sdd at scsi0, channel 0, id 4, lun 0 I think this is caused by the addition of module_init(init_sd); at the end of drivers/scsi/sd.c. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Scsi disks duplicated
On Sat, Sep 09, 2000 at 07:25:53PM +0200, Torben Mathiasen wrote: > This seems to some kind of scsi weirdness. Jens reports its the > same with sr. Maybe Eric have a comment on this? Some additional datapoints: I just commented out the last two lines of sd.c: --- sd.c.orig Sat Sep 9 17:47:46 2000 +++ sd.cSat Sep 9 17:47:57 2000 @@ -1388,5 +1388,5 @@ kfree(sd_gendisks); } -module_init(init_sd); -module_exit(exit_sd); +/*module_init(init_sd); +module_exit(exit_sd);*/ Now -test8 works for me (with the duplicated scsi devices, lvm didn't work). This patch may break scsi modules - I have scsi compiled into the kernel and didn't test modules. But it seems obvious to me that with module_init(init_sd), the partition detection code runs twice: once after hardware detection, and once when the module_init()-Functions get called. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test8 LVM(vgscan) on SCSI problems (report)
On Sun, Sep 10, 2000 at 03:55:46PM +0200, [EMAIL PROTECTED] wrote: > With 2.4.0-test8 (test8-pre6 seems to be OK) vgscan (at > boottime) "sees" al my volumegroups which are on IDE disk, but not those > on SCSI disk. > I had no problems mounting a "plain" ext2 scsi partition on same disk. Yes, if you look at /proc/partitions, you'll find that all scsi disks are duplicated. This confuses LVM and it doesn't activate any VG that contains partitons on SCSI drives. If you comment out the last two lines of sd.c (module_init) LVM works again. I don't know if this may cause other problems, but I'm just running such a patched -test8 kernel. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
emu10k1 reversing channels
The current kernel is reversing the right and left channels on emu10k1 sound cards. After isolating and fixing the bug, I found out the fix is already in the current CVS on http://opensource.creative.com/ :-| I think it should be included in the official kernel. Patch attached. Jan --- linux-2.4.0-test8/drivers/sound/emu10k1/main.c.orig Tue Sep 12 00:20:59 2000 +++ linux-2.4.0-test8/drivers/sound/emu10k1/main.c Tue Sep 12 00:55:16 2000 @@ -121,14 +121,14 @@ /* stereo voice */ card->waveout.send_a[1] = 0x00; -card->waveout.send_b[1] = 0xff; -card->waveout.send_c[1] = 0x00; +card->waveout.send_b[1] = 0x00; +card->waveout.send_c[1] = 0xff; card->waveout.send_d[1] = 0x00; card->waveout.send_routing[1] = 0xd01c; card->waveout.send_a[2] = 0x00; -card->waveout.send_b[2] = 0x00; -card->waveout.send_c[2] = 0xff; +card->waveout.send_b[2] = 0xff; +card->waveout.send_c[2] = 0x00; card->waveout.send_d[2] = 0x00; card->waveout.send_routing[2] = 0xd01c;
Re: Masking out one page of RAM because of bit-errors.
On Tue, Sep 12, 2000 at 06:18:36PM +0200, Patrick Mau wrote: > I have a bad SDRAM chip with exactly one bit error. Memtest86 shows > that the bit error always occurs at the address 0x4eff508. I tried > to calculate the page number and it should be 20223. There is a patch on http://home.zonnet.nl/vanrein/badram/ to avoid using bad ram pages. I didn't test it - my ram is good ;-) (at least the ram in my computer - I'd like to see a port of this program to my own brain...) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
SCSI scanning
test9-pre1 does not contain a fix for the test8 scsi scanning problem. SCSI disks are detected twice if scsi is not compiled as a module. Torben already posted a patch. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: SCSI scanning
On Sun, Sep 17, 2000 at 09:59:30AM -0700, Linus Torvalds wrote: > On Sun, 17 Sep 2000, Torben Mathiasen wrote: > > > > The proper way of fixing this is to add #ifdef MODULE around the init > > functions or going back to init/exit_module. > > Please explain why it does it twice for compiled-in, and only once for > modules. There must be some other logic that does the extra > initializations (and that does not trigger for modules), and I'd much > rather just get rid of THAT thing instead. The call to sd_init is in lines 1577ff of scsi.c : for (sdtpnt = scsi_devicelist; sdtpnt; sdtpnt = sdtpnt->next) if (sdtpnt->init && sdtpnt->dev_noticed) (*sdtpnt->init) (); Just commenting this out is curing the biggest problem (at least for me), as now the scsi discs show up only once in /proc/partitions. But there is still a duplicated "Detected scsi disk" message, so not everything is fine. Further investigation shows that this duplication is caused by the call to scan_scsis in line 1565 of scsi.c, and this one can not be commented out as it is needed. But I have some problems understanding all the module/non-module stuff: hosts.c, lines 1002-1004, look as follows: #ifdef CONFIG_BLK_DEV_SD scsi_register_device(&sd_template); #endif If I understand that correctly, the line is executed for both CONFIG_BLK_DEV_SD=m and CONFIG_BLK_DEV_SD=y, isn't it? But if sd is compiled as a module, sd_template should not be available, as it's defined inside sd.c. > Basically, there has to be some other place that does the equivalent of > > if (!module) init_subsystems(); As I said above, this if(!module) is probably the #ifndef MODULE section in scsi.c. > and I don't see why we can't just remove that one and make modules and > compiled-in behave the same. We probably should, but this would mean changes to scsi.c, hosts.c, and perhaps scsi_module.c, which is included in every low level scsi driver. This may not be a change we want to do in 2.3, the additional #ifdef MODULE in sd.c and sr.c is a much smaller change. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
test9-pre5: Mouse doesn't work with uhci
My IntelliMouse Explorer USB doesn't work with test9-pre5 if I use the uhci.o module. With usb-uhci.o, it does work fine. The last kernel I tried was pre9-test2, which was ok. Other details: modules loaded: usbcore uhci (or usb-uhci) input usbmouse mousedev XFree 4.0.1 Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lvm in 2.4.0-test9pre5
On Wed, Sep 20, 2000 at 08:54:55PM -0400, Mohammad A. Haque wrote: > I think lvm and lvm-snap didn't get moved into the md dir. Or maybe the > Makefile in md needs to be fixed. Yes, lvm.c and lvm-snap.c are missing from drivers/md/. Additionally, drivers/Makefile needs to be modified: If you use lvm as a module, and do not use md, the md directory is not included in MOD_SUB_DIRS. I just added ifeq ($(CONFIG_BLK_DEV_LVM),y) SUB_DIRS += md MOD_SUB_DIRS += md else ifeq ($(CONFIG_BLK_DEV_LVM),m) MOD_SUB_DIRS += md endif endif and now lvm works again. I don't know if this is correct if both md and lvm are used, as then MOD_SUB_DIRS will contain 'md' twice. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: lvm in 2.4.0-test9pre5
On Thu, Sep 21, 2000 at 05:47:36PM +0200, Andrea Arcangeli wrote: > On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote: > > Yes, lvm.c and lvm-snap.c are missing from drivers/md/. > > LVM and MD have nothing common. Yes, I know. I'm not arguing about the right location for lvm. But lvm has been moved from drivers/block/Makefile to drivers/md/Makefile, so lvm.c has to follow. (Or Makefile has to be changed again) If lvm is in drivers/md or in drivers/lvm is a matter of taste. drivers/lvm is more logical, but having another directory for only two source files? Putting it in the same directory as md is not too bad, because both do similar things: They take existing block devices and somehow combine them to a bigger one. Put it wherever you want. I just don't care. But make it work. ;-) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: bzImage ~ 900K with i386 test11-pre2
On Sat, Nov 11, 2000 at 03:27:36AM -0800, Max Inux wrote: > >gzip, actually. I can verify here "make bzImage" does the expected thing > >and it looks normal-sized to me. > > I believe there is zImage (gzip) and bzImage (bzip2). (Or is it compress > vs gzip, but then why bzImage vs gzImage?) IMHO bzImage means something like 'big zImage', it uses the same compression but a different loader. IIRC bzImage became necessary when the (uncompressed) kernel grew above 1MB. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: fs corruption with invalidate_buffers()
On Thu, Dec 07, 2000 at 05:26:46PM -0500, Alexander Viro wrote: > That invalidate_buffers() should leave the unhashed ones alone. If it can't > be found via getblk() - just leave it as is. > > IOW, let it skip bh if (bh->b_next == NULL && !destroy_dirty_buffers). > No warnings needed - it's a normal situation. Yes, if(bh->b_next == NULL && !destroy_dirty_buffers) seems to work, too. I wonder why, because, if I analysed the problem correctly, it was caused by the page mapping. Or is it a general rule that bh->b_next==NULL if bh->b_page->mapping != NULL, ie. a buffer is never directly hased and belongs to a mapped page? Is there a place one can look for documentation about these things? Another question is what should happen with the mapped pages? Whoever calls invalidate_buffers(), probably does it because the underlying device disappered or changed, so the page mappings should be invalidated, too. OTOH, pages are (normally) mapped through inodes, and if the inode stays valid after the invalidate_buffers() (ie. if it's called by an lvm resize event), the page mapping stays valid, too. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Re: fs corruption with invalidate_buffers()
The file corruption I reported on Dec 6 is still there in test13-pre3.
(I can only reproduce it easily with the ext2 online resizing patches,
but I really don't think it is caused by them)
The corruption happens if invalidate_buffers calls put_last_free() on
buffers that belong to mapped pages. These pages remain valid and may
get used later, while the buffers are marked free and may be reused
by something completely different, immediately causing corruption.
I changed my patch for the problem according to the following advice by
Al Viro:
On Thu, Dec 07, 2000 at 05:26:46PM -0500, Alexander Viro wrote:
> That invalidate_buffers() should leave the unhashed ones alone. If it can't
> be found via getblk() - just leave it as is.
>
> IOW, let it skip bh if (bh->b_next == NULL && !destroy_dirty_buffers).
> No warnings needed - it's a normal situation.
This is the result - against test12-pre7, but works well with
test13-pre3:
--- linux-2.4.0-test12-pre7-jn/fs/buffer.c.orig Fri Dec 8 14:59:28 2000
+++ linux-2.4.0-test12-pre7-jn/fs/buffer.c Fri Dec 8 15:05:11 2000
@@ -502,6 +502,10 @@
struct bh_free_head *head = &free_list[BUFSIZE_INDEX(bh->b_size)];
struct buffer_head **bhp = &head->list;
+ if(bh->b_page && bh->b_page->mapping) {
+ panic("put_last_free() on mapped buffer!");
+ }
+
bh->b_state = 0;
spin_lock(&head->lock);
@@ -652,7 +656,8 @@
write_lock(&hash_table_lock);
if (!atomic_read(&bh->b_count) &&
- (destroy_dirty_buffers || !buffer_dirty(bh))) {
+ (destroy_dirty_buffers ||
+ (!buffer_dirty(bh) && bh->b_next!=0) )) {
remove_inode_queue(bh);
__remove_from_queues(bh);
put_last_free(bh);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: fs corruption with invalidate_buffers()
On Thu, Dec 21, 2000 at 04:37:30PM -0800, Linus Torvalds wrote: > This looks bogus. It may be - I just did what Al told me without really understanding it ;-) The test I did initially was the following: if(!atomic_read(&bh->b_count) && (destroy_dirty_buffers || !buffer_dirty(bh)) && ! (bh->b_page && bh->b_page->mapping) ) That is, I was explicitely checking for a mapped page. It worked well, too. Is this more reasonable? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Re: fs corruption with invalidate_buffers()
On Thu, Dec 21, 2000 at 05:01:00PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 22 Dec 2000, Jan Niehusmann wrote:
> >
> > The test I did initially was the following:
> >
> > if(!atomic_read(&bh->b_count) &&
> > (destroy_dirty_buffers || !buffer_dirty(bh))
> > && ! (bh->b_page && bh->b_page->mapping)
> > )
> >
> > That is, I was explicitely checking for a mapped page. It worked well, too.
> > Is this more reasonable?
>
> I'd suggest just doing this instead (warning: cut-and-paste in xterm, so
> white-space damage):
> which just ignores mapped buffers entirely (and doesn't test for
> bh->b_page being non-NULL, because that shouldn't be allowed anyway).
Yes, looks good to me, and passes some tests. Here is a patch that has not
been cut and pasted:
--- linux/fs/buffer.c.orig Thu Dec 21 20:30:03 2000
+++ linux/fs/buffer.c Fri Dec 22 02:11:29 2000
@@ -643,7 +643,12 @@
continue;
for (i = nr_buffers_type[nlist]; i > 0 ; bh = bh_next, i--) {
bh_next = bh->b_next_free;
+
+ /* Another device? */
if (bh->b_dev != dev)
+ continue;
+ /* Part of a mapping? */
+ if (bh->b_page->mapping)
continue;
if (buffer_locked(bh)) {
atomic_inc(&bh->b_count);
I have one additional question: invalidate_buffers normally gets called if
someone wants to make sure that, after the call, read accesses to a device
really go to the device and don't get served by a cache. Is there some
mechanismn that does the same thing to mapped pages?
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: lvm in 2.4.0-test9pre5
> But I don't think there is anything wrong with grouping RAID and LVM under > the title "md", and just leaving it as such. It seems that the current setup makes it impossible to compile lvm without compiling md.c. But md.c is not needed for lvm, is it? I think we need two different config options now: One to enable the drivers/md/ directory, and one to compile md.c. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Multiple access to drives
On Tue, Sep 26, 2000 at 11:28:29AM +, Heinz J. Mauelshagen wrote:
> Wondering if it is a bug or a feature ;-{)
Bug, known, and already fixed in the test9-pre series.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: mount -t bind gone?
On Mon, Sep 25, 2000 at 10:11:37PM +0200, Jasper Spaans wrote: > A simple solution: update your version of mount, and try > > mount --bind /foo /bar Is there a way to place such a mount in fstab? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Mon, Oct 02, 2000 at 02:11:33AM -0400, Mohammad A. Haque wrote: > Broke md as module. I guess this is one way to fix it. I propose the following patch. It fixes lvm modules, too. Jan --- linux-2.4.0-test9-pre8/drivers/Makefile.origMon Oct 2 12:49:03 2000 +++ linux-2.4.0-test9-pre8/drivers/Makefile Mon Oct 2 12:43:18 2000 @@ -31,7 +31,8 @@ subdir-$(CONFIG_I2O) += i2o subdir-$(CONFIG_IDE) += ide subdir-$(CONFIG_SCSI) += scsi -subdir-$(CONFIG_MD)+= md +subdir-$(CONFIG_BLK_DEV_MD)+= md +subdir-$(CONFIG_BLK_DEV_LVM) += md subdir-$(CONFIG_IEEE1394) += ieee1394 subdir-$(CONFIG_PNP) += pnp subdir-$(CONFIG_ISDN) += isdn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9-pre8
On Mon, Oct 02, 2000 at 08:32:40AM -0400, Mohammad A. Haque wrote: > This would make more sense wouldn't it. I guess it doesn't help to look > right before heading off to bed. Please note that my patch still has problems: It doesn't work with CONFIG_BLK_DEV_MD and CONFIG_BLK_DEV_LVM both =y. Christoph Hellwig sent me a better patch, with Cc: to Linus, so I hope this will be fixed in test9. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9: USB-Mouse half recognized
On Wed, Oct 04, 2000 at 12:27:05PM +0200, Meino Christian Cramer wrote: > Then I start X (XFree86 v.:4.01) which starts -- so it sees > something like a "mouse" (otherwise the server will stop > immediately), but I am not able to move the cursor. > > Back on the console again I did this cat thing again, and > it doesn't work anymore. If you use 'uhci' instead of 'usb-uhci', it works again. Interestingly, we had the very same problem with some test9-pre-patches, but it was fixed in the later ones. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9: USB-Mouse half recognized
On Wed, Oct 04, 2000 at 12:34:41PM +0200, Jan Niehusmann wrote: > On Wed, Oct 04, 2000 at 12:27:05PM +0200, Meino Christian Cramer wrote: > > Then I start X (XFree86 v.:4.01) which starts -- so it sees > > something like a "mouse" (otherwise the server will stop > > immediately), but I am not able to move the cursor. > > > > Back on the console again I did this cat thing again, and > > it doesn't work anymore. > > If you use 'uhci' instead of 'usb-uhci', it works again. Interestingly, > we had the very same problem with some test9-pre-patches, but it was > fixed in the later ones. I have to correct myself: with test9-pre5, it was exactly the opposite: usb-uhci was ok, uhci was not. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test9: USB-Mouse half recognized
On Wed, Oct 04, 2000 at 04:15:54PM +0200, Meino Christian Cramer wrote: > I tried it both: uhci and usb.uhci: > Same behaviour for both: Boot into runlevel 2. do a cat on > /dev/input/mouse0 and move the mouse: OK, some glibberish bytes > found their way onto the console. Oh well you're right... but I have a workaround (that made me think the other driver works): Start X. The mouse doesn't work. Switch to a console. rmmod uhci; modprobe uhci Switch back to X. Now the mouse works. (until you switch away from X, again) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Updated 2.4 TODO List
> argued that critical routines should always be compiled with -i386, > unfortunately that includes all of printk and all console handling > (both serial and screen), not really an option. Neither printk nor console handling should be too performance critical, and the performance of console i/o is probably not limited by processor speed, so compiling them for i386 should not make a big difference. (Note that this is a guess - I did no benchmarks!) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cannot connect to linuxtoday.com 80 with test9-pre9
On Fri, Oct 13, 2000 at 10:32:32AM +, Peter Samuelson wrote: > > Is there anyway that we could make ECN enable/disable a flag on a route? > > Would it help? It seems to me that typically, your busiest, best- If it is configurable per route (and not per interface), it may help, as you could add additional routes for sites not supporting ECN. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: cannot connect to linuxtoday.com 80 with test9-pre9
On Fri, Oct 13, 2000 at 06:29:32AM -0500, Peter Samuelson wrote: > Right you are, both of you. I guess was confusing 'route' with > 'interface' and didn't think of using multiple routes like that. It > would be a kludge but whatever gets the job done.. Another idea: What about making it an netfilter thing? I'm thinking about a possibility to say the kernel 'if this and that netfilter rule matches, delete the ECN bits'. ECN handles routes which drop ECN bits, it just looks as if the remote end doesn't know about ECN. That way, if you have a network of ECN capable machines, you don't need to configure the broken links on every single computer, but can do it on the router/firewall to your network. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Weird device out-of-space error
On Sat, Oct 14, 2000 at 08:00:38AM -0400, safemode wrote: > cvs server: cannot rewrite CVS/Entries.Backup: No space left on device > > These are the sort of errors i'm getting from cvs but this is what df -m > tells me on the partition i'm downloading on > /dev/hda4 6865 4899 1610 76% / try df -i, perhaps you have no inodes left. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: hotmail can't deal with ECN
On Fri, Jan 26, 2001 at 11:50:57AM +1100, CaT wrote: > I'm not sure as to what the problem with hotmail may be. I have ECN > turned on: > > gozer:~# more /proc/sys/net/ipv4/tcp_ecn > 1 > > and I can contact hotmail just fine. I also can ftp to your site > non-passively. where should I go to on hotmail to see it fail? You may be located behind a firewall that zeroes out the ECN bits. This would mean that hotmail doesn't get ECN packets and the connection gets established just as if you were talking to a plain non-ECN server without a firewall. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
/dev/rtc not working on ASUS A7V133
If my ASUS A7V133-based computer got started by the bios automatic startup timer, /dev/rtc doesn't work properly. /proc/drivers/rtc shows sane values, but IRQ 8 is not triggered causing programms like 'hwclock' to hang. I assume this is not a kernel bug but a BIOS problem, but it would be nice if a kernel workaround was possible. Does anybody have an idea what I could try to reenable the interrupts? Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: /dev/rtc not working on ASUS A7V133
On Mon, Feb 12, 2001 at 02:15:32AM +0100, Guest section DW wrote: > I suppose you could give hwclock --directisa ? I didn't try --directisa, but I did remove /dev/rtc, which, according to hwclock's manpage should have the same effect. Afterwards hwclock does work well. But I have a correction: The problem does not only occurr if the system was started automatically by the bios, a manual 'soft off/soft on' sequence shows the same effect. Only 'hard off/hard on' (using the switch directly on the power supply) seems to work every time. Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.[01] and duron - unresolved symbol _mmx_memcpy
On Mon, Feb 12, 2001 at 08:04:59AM +0100, Ph. Marek wrote: > The offending function is _mmx_memcpy, which can be found in the System.map > (but, opposed to other functions, with an upper "T" instead of "t"). I had the same problem after I accidentally compiled the kernel with SMP support. make mrproper did help. (safe your .config before trying it) Jan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] zero disk pages used by swsusp on resume
> Andreas is right, his patches are needed. > > Currently, if your laptop is stolen after resume, they can still data > in swsusp image. Which shows that swsusp is a security risk if you have sensitive data in RAM. A thief stealing a running computer can get access to memory contents much more easy if he can just suspend the system and then recover all the memory contents from disk. Encrypted swsusp wouldn't help here if the key is stored on the disk as well. (This is probably not a real risk in most applications, but one should keep it in mind and disable swsusp if necessary) Jan - 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/
key bounce problem with 2.6.11-rc5
Hi, since I upgraded my ASUS M2400N laptop from 2.6.10 to 2.6.11-rc5, I got an annoying key bounce problem. I'm not sure if it's purely a kernel problem, because it seems to occur only in xwindows, but booting back to 2.6.10 made the bouncing disappear, and 2.6.11-rc5 seems to contain some changes to the keyboard driver. It looks like the sequence of events is the following: Usually, when I press a key, the char shows up on the screen immediately. But sometimes, the char does not show up until I press a second key, and in that moment, the first char shows up twice, together with the second one. (But I may be wrong with that observation, because the sequence of events is really fast - it's more like an impression than a real observation) What can I do to help debugging that problem? Are there certain -rc versions between 2.6.10 and 2.6.11-rc5 you want me to try out? Yours, Jan - 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/
bouncing keys and skipping sound with 2.6.11
Hello, the problem with bouncing keys I reported with 2.6.11-rc5 is still present in 2.6.11. Additionally, I noticed that audio has short outages every few seconds, which sound like latency problems would do. And I saw with 'top' that often, when the sound skips, the kacpid process shows up using a big percentage of CPU time. (Perhaps it's always the kacpid waking up, but 'top' is just to slow to show it accurately) Have there been changes between 2.6.10 and 2.6.11-rc5 which could cause these problems, perhaps together with ACPI bugs on the ASUS M2400N or anything like that? I'd be happy helping to debug this, if anybody could give me a hint where to start. Yours, Jan - 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: bouncing keys and skipping sound with 2.6.11
On Wed, Mar 02, 2005 at 09:06:32PM +0100, Jan Niehusmann wrote: > the problem with bouncing keys I reported with 2.6.11-rc5 is still > present in 2.6.11. Additionally, I noticed that audio has short outages By trying different kernel versions, I traced down the problem to the changes introduced between linux-2.6.11-rc2-bk9 and linux-2.6.11-rc2-bk10, and, more specifically, to the ACPI changes within that patch. (Therefore the Cc: to Len Brown, who wrote or submitted most of these changes, as far as I can tell from the changelog) Len, do you have any idea which of the ACPI changes could have caused the described key bouncing problems on my ASUS M2400N laptop, or how I could debug this? Yours, Jan - 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: bouncing keys and skipping sound with 2.6.11
On Mon, Mar 07, 2005 at 08:26:32AM +0100, Stefan Seyfried wrote: > I bet you have CONFIG_ACPI_DEBUG enabled. Disable it or try to put > #define ACPI_ENABLE_OBJECT_CACHE 1 > at the end of include/acpi/acpi.h (before the last #endif) > This fixed it for me (and some others). ...and for me - thanks for the hint, I've been running 2.6.11 now for a few days without any problems. Jan - 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/
panic when booting 2.4.4
I get the following kernel panic when booting 2.4.4. (2.4.3 works fine) This is on an asus-a7v133 (VIA chipset), Duron 800, HD is hda, CDRW is hdc, no other ide devices attached (ie no devices on the onboard promise controller) gcc version 2.95.4 20010319 (Debian prerelease) (the working 2.4.3 has been compiled with the same gcc version) Jan ksymoops 2.4.1 on i686 2.4.3. Options used -V (specified) -K (specified) -L (specified) -o /lib/modules/2.4.4 (specified) -m /boot/System.map-2.4.4 (specified) No modules in ksyms, skipping objects Unable to handle kernel NULL pointer dereference at virtual address 0024 c02532a8 *pde = Oops: CPU:0 EIP:0010:[] Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010282 eax: ebx: ecx: 0001 edx: c144c800 esi: c144c800 edi: 0003e308 ebp: esp: cffe7f34 ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 1, stackpage=cffe7000) Stack: c0258524 c144c800 0003e308 0008e000 0001 c027e351 cffe7f76 000a 0001 0286 0001 c027e351 002e 0002 0007fae0 c0253bf4 c144c800 c0258524 c144c800 5556 c0253c1c c144c800 Call Trace: [] [] Code: 81 78 24 86 80 60 09 75 12 68 00 f8 20 c0 e8 75 01 ec ff 83 >>EIP; c02532a8<= Trace; c0105007 Trace; c0105488 Code; c02532a8 <_EIP>: Code; c02532a8<= 0: 81 78 24 86 80 60 09 cmpl $0x9608086,0x24(%eax) <= Code; c02532af 7: 75 12 jne1b <_EIP+0x1b> c02532c3 Code; c02532b1 9: 68 00 f8 20 c0push $0xc020f800 Code; c02532b6 e: e8 75 01 ec ffcall ffec0188 <_EIP+0xffec0188> c0113430 Code; c02532bb 13: 83 00 00 addl $0x0,(%eax) Kernel panic: Attempted to kill init! - 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: panic when booting 2.4.4
On Sun, Apr 29, 2001 at 12:43:17PM -0700, Manuel McLure wrote: > Does your motherboard have a Promise FastTrak on it? If so this is a bug I > reported in 2.4.3-ac10/11 and that Alan Cox fixed in -ac12 - for some > reason it didn't make it into 2.4.4. I was just about to report it myself > when I saw your mail. The following patch fixes: Yes, the patch fixed the problem! - 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: LANANA: To Pending Device Number Registrants
On Mon, May 14, 2001 at 11:21:00PM +0100, Alan Cox wrote: > You can make it a string if you like but at the end of the day > has to be an opaque handle. For constant devices it also has to be > a constant name. Otherwise the /dev file I archived with the corporate > backup system turns out to be a different device when I restore the > box after a problem and I reformat the wrong disk... Why can't we configure this in user space? I think of something like /etc/major-numbers. We could then tell the kernel at module load time what major number to use for a given driver. The corporate backup system then only needs to restore /dev and /etc/major-numbers at the same time. I don't think this is the ideal solution. But it has some nice properties: - no policy in kernel. Neither device names nor numbers are hard-coded - no daemons needed, only some simple startup scripts - no special filesystems needed, /dev is simple tar-compatible directory - everybody can add drivers to his system as he wants, without the need to register a number. One entry in a config file is enough - every single system only needs as many major numbers as there are drivers - so even 256 majors should be enough in most cases. (this may be limited by the fact that the existing numbers should be recommended as standard entries in /etc/major-numbers to stay backward compatible) Of course there are disadvantages, the biggest problem I see are drivers compiled into the kernel. They need to get their major number from the command line, I think, which is pretty ugly. Perhaps the above is pure bullshit and my proposal is not working for serveral reasons. But I think we should try to define our requirements to the device numbering/naming system, and then find a solution that meats these requirements - the final reason for choosing one solution should be a technical one, not personal preference. Jan - 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: [BUG/REGRESSION] Screen flickering
Hi, On Wed, May 13, 2015 at 12:14:39PM +0300, Jani Nikula wrote: > Is this the same as https://bugzilla.kernel.org/show_bug.cgi?id=98141 ? The visible effect in the video is similar to what I see on the LVDS display. I also see some influence of the mouse pointer position on the blanked areas. The effect on the external screen is more like single scan lines jumping to the right and back, at a high (but still visible) frequency. What I'm missing in the report, are some log entries I'm seeing on my notebook: Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO underrun Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder A FIFO underrun Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG/REGRESSION] Screen flickering
On Wed, May 13, 2015 at 04:02:25PM +0530, Sudip Mukherjee wrote: > > What I'm missing in the report, are some log entries I'm seeing on my > > notebook: > > > > Apr 30 08:50:23 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler > > [i915]] *ERROR* CPU pipe B FIFO underrun > > Apr 30 08:50:23 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler > > [i915]] *ERROR* PCH transcoder B FIFO underrun > > Apr 30 08:50:29 localhost kernel: [drm:intel_cpu_fifo_underrun_irq_handler > > [i915]] *ERROR* CPU pipe A FIFO underrun > > Apr 30 08:50:29 localhost kernel: [drm:intel_pch_fifo_underrun_irq_handler > > [i915]] *ERROR* PCH transcoder A FIFO underrun > hi, > I also have the similar entries in my dmesg, though my problem is a > little different from yours and my bisect lead to another commit. > And that also is still not fixed (last tested with 4.0). (Please note that I didn't do a bisect - that was Thomas. I only noted that I can confirm his observations and that his patch helps to prevent or hide the issue.) Perhaps these are two completely unrelated issues? Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] i915: fix screen flickering
On Wed, Apr 29, 2015 at 12:23:43AM +0200, Thomas Gummerer wrote: > I forgot to mention, the bug only occurs after suspending the system and > waking it up again. In that case, moving the mouse pointer around on > the build in laptop screen triggers the flickering, while the external > monitor works just fine. My Lenovo X201s shows the same symptoms with v4.1.0-rc1, and your patch seems to help. Another detail: The flickering only happens when both outputs are active, using xrandr to disable one output makes the other one working fine, again. > Might be unrelated, but I only managed to trigger the bug when the > system is suspended after the synergy server has started. I don't have synergy installed, so this can't be a strict requirement for triggering the bug. Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspend broken on Thinkpad x201s since 4.7-rc1
Hi, when trying out 4.7-rc1 on my Thinkpad x201s, I noticed that suspending the system doesn't work any more. Instead, when trying to suspend, the system hangs with a black screen and the suspend-LED blinking. I bisected the issue to commit 22e2f9fa63b092923873fc8a52955151f4d83274, and indeed, reverting this commit from 4.7-rc1 fixes the issue. As the system just hangs on suspend, I don't have any error message to quote. But if there is something I could try to get some diagnostics, please let me know. Jan
Re: Dell XPS13 does not suspend with Linux 4.10-rc3
Hi,
On Tue, Jan 10, 2017 at 03:08:32PM +0100, Paul Menzel wrote:
> Testing Linux 4.10-rc{1,2,3} the Dell XPS13 does not suspend with the
> attached configuration. The screen turns black, but the power button never
> goes dark. The white light stays always on.
Same here.
And I bisected the issue to commit 7279b238ba, "mei: send OS type to the
FW"
Suspending from the console with no_console_suspend shows that the last
message is "e1000e: EEE TX LPI TIMER: " (which is probably
unrelated).
More interesting is the first message missing, ie. the one after the one
mentioned when using a working kernel: "ACPI : EC: event blocked".
This seems to be related to the bisected commit. Maybe it's not even the
kernel's fault, but the EC just happens to change it's behavior when it
got told about the OS type, before?
Jan
Re: Dell XPS13 does not suspend with Linux 4.10-rc3
On Tue, Jan 10, 2017 at 09:43:31PM +0100, Jan Niehusmann wrote:
> And I bisected the issue to commit 7279b238ba, "mei: send OS type to the
> FW"
Indeed, just disabling the FIXUP implemented by that commit fixes
suspend for me, with 4.10.0-rc3. Btw, this is on a Thinkpad x201s.
(For the addressees newly added to cc, it seems like the mentioned
commit breaks suspend to ram on Dell XPS13 and Thinkpad x201s)
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -406,3 +406,3 @@ static struct mei_fixup {
MEI_FIXUP(MEI_UUID_WD, mei_wd),
- MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
+// MEI_FIXUP(MEI_UUID_MKHIF_FIX, mei_mkhi_fix),
};
I don't know what this may break, as the description of 7279b23 just
says:
"This workaround was added to support other broken OS and we need to
follow here."
Unless there is a better justification, I think the commit should be
reverted, for now.
Jan
Re: [char-misc for 4.10-rc4 V2] mei: bus: enable OS version only for SPT and newer
On Wed, Jan 11, 2017 at 01:27:21AM +0200, Tomas Winkler wrote: > On older platforms the command should be just ignored by the firmware > but some older platforms misbehave so it's safer to send the command > only if required. Thanks! This fixes suspend-to-ram for me (on a Thinkpad x201s). Jan
[PATCH] iommu/vt-d: fix overflow of iommu->domains array
The valid range of did in get_iommu_domain(*iommu, did)
is 0..cap_ndoms(iommu->cap), so don't exceed that
range in free_all_cpu_cached_iovas().
Signed-off-by: Jan Niehusmann
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a644d0c..82989d4 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4600,7 +4600,7 @@ static void free_all_cpu_cached_iovas(unsigned int cpu)
if (!iommu)
continue;
- for (did = 0; did < 0x; did++) {
+ for (did = 0; did < cap_ndoms(iommu->cap); did++) {
domain = get_iommu_domain(iommu, did);
if (!domain)
--
2.1.4
