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
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
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
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
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
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
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 <j...@gondor.com>
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
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/in
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,
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,
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
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.
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
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.
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
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
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
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
> 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
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
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
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
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 intr
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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:
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
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 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
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
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
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
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
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(>b_count) &&
> > (destroy_dirty_buffers || !buffer
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(>b_count) &&
(destroy_dirty_buffers || !buffer_dirty(bh))
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.
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.
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))
!
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
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
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
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()
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()
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
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
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
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
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
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
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
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
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
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?)
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
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
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
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
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
> 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
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
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
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
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
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
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.
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
+++
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.
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
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]
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]
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
> 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
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
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 l
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
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)
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
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
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,
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
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]
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]
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
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
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
---
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
---
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
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
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
1 - 100 of 103 matches
Mail list logo
