On Thu, Aug 2, 2018 at 8:29 PM, Alan Cox wrote:
>> # hdparm --user-master u --security-erase p /dev/sda
>> (returns immediately and does nothing).
>>
>> I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.
>>
>> Anyone working on this?
>
> Sounds to me like you need to contact t
On Wed, Aug 1, 2018 at 1:02 PM, Jeff Chua wrote:
> On Tue, Jul 31, 2018 at 7:07 PM, Ming Lei wrote:
>> On Sun, Jul 29, 2018 at 5:09 PM, Jeff Chua wrote:
>>> I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
>>> recognized it as /dev/sda.
On Tue, Jul 31, 2018 at 7:07 PM, Ming Lei wrote:
> On Sun, Jul 29, 2018 at 5:09 PM, Jeff Chua wrote:
>> I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
>> recognized it as /dev/sda.
>>
>> Since it's an USB device, the nvme-cli tools
I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
recognized it as /dev/sda.
Since it's an USB device, the nvme-cli tools won't work, nor does
hdparm, as it's a NVME SSD.
So, how to secure-erase the NVME SSD connected via the JMS583 chip?
Thanks,
Jeff.
On Thu, May 26, 2016 at 3:46 PM, Hillf Danton wrote:
>> > See if this fixes your reproducer.
>> >
>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> > index b11945e..49b8eab 100644
>> > --- a/fs/xattr.c
>> > +++ b/fs/xattr.c
>> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler
>> > **
On Wed, May 25, 2016 at 11:51 PM, Al Viro wrote:
> On Wed, May 25, 2016 at 05:30:22PM +0800, Jeff Chua wrote:
>> On Wed, May 25, 2016 at 2:37 AM, Al Viro wrote:
>> > On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>> >
>> >> Umm... Any chance o
On Wed, May 25, 2016 at 2:37 AM, Al Viro wrote:
> On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>
>> Umm... Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> See if this fi
On Wed, May 25, 2016 at 12:10 AM, Linus Torvalds
wrote:
> On Tue, May 24, 2016 at 8:59 AM, Al Viro wrote:
>>
>> Umm... Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> Yeah, we shou
Seems to break after index 348619f..d55dc5a 100644
Boot up with ext4 works, but try anything to access anything on the
reiser partition such as "/mnt/bin/passwd" resulted in the following
...
[ 93.380353] BUG: unable to handle kernel NULL pointer dereference
at (null)
[ 93.380924] I
On Thu, Sep 17, 2015 at 9:50 AM, Dave Chinner wrote:
> On Mon, Sep 07, 2015 at 01:29:33PM +0800, Jeff Chua wrote:
>> When umount a slow device such as an SD card, the command will take a
>> while to run depending on how much data is left to write to the
>> device. Is there
When umount a slow device such as an SD card, the command will take a
while to run depending on how much data is left to write to the
device. Is there way to check how much data is remaining waiting to
write to the device?
Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe
On Thu, Jun 25, 2015 at 2:08 PM, Martin Steigerwald wrote:
> Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman:
>> On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote:
>> > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
>> >
>> > wrot
On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
wrote:
> On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
>> Both sda and sdb have the same SSD model.
>
> That's a bug in your USB bridge chip, odds are it is not reporting the
> value properly. There's
On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald wrote:
> Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du:
>> Hi,
>
> Hi,
>
>> [proper In-Reply-To trail missing since lkml.org now fails to provide it]
> […]
>> > Greg,
>> >
>> > SSD is coming mainstream and it doesn't make sense wasting time
>
On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
wrote:
> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
>>
>> There's no need to wait for disk spin-up for USB SSD devices. This patch
>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 d
There's no need to wait for disk spin-up for USB SSD devices. This
patch allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1
during boot-up.
If there's a better way to handle this, please share.
Thanks,
Jeff
--- linux/drivers/scsi/sd.c 2015-05-25 07:29:44.0 +0800
I started seeing this behavior somewhere around 3.16 with
CONFIG_PREEMPT set. Setting CONFIG_PREEMPT off seems to help. And,
yes, it happens on high load (compiling mozilla, xul) and using qemu
chroot to compile mesa.
I'm seeing a few persons bisecting already. If you want, I could start
bisecting
On Fri, Jun 13, 2014 at 8:28 PM, Ulf Hansson wrote:
> On 13 June 2014 01:51, John Stultz wrote:
>> On Wed, Jun 11, 2014 at 10:35 PM, John Stultz john.stu...@linaro.org> wrote:
> I have quickly implemented my proposal 1). I am testing them on real
> HW now, will post the patches as soon as I can
commit ab81cbf99c881ca2b9a83682a8722fc84b2483d2
Author: Johan Hedberg
Date: Wed Dec 15 13:53:18 2010 +0200
Bluetooth: Implement automatic setup procedure for local adapters
A new HCI_AUTO_OFF flag is added that user space needs to clear to
avoid the automatic power off
Help, how do I cle
Here's my .config ...
On Wed, Feb 19, 2014 at 5:32 AM, Theodore Ts'o wrote:
> On Tue, Feb 18, 2014 at 09:28:02PM +0100, Takashi Iwai wrote:
>>
>> I checked CONFIG_SND_HDA_INTEL=y on my HP laptop with Haswell, but it
>> worked fine. Could you give config?
>
> I don't have that config any more.
On Sat, Feb 15, 2014 at 4:07 AM, Takashi Iwai wrote:
>> # bad
>> CONFIG_SND_HDA_CODEC_HDMI =y
>> CONFIG_SND_HDA_INTEL=y
>> CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_GENERIC=m
>
> It might be the remaining bugs of modularization in 3.14-rc2.
> A few patches are found in for-linus branch of sound
On Fri, Feb 14, 2014 at 9:57 PM, Takashi Iwai wrote:
> The other possible change in hda_intel.c is the enablement of runtime
> PM for Panther Point. But it's been working for other chips, so
> wondering why it hits anything. In anyway, please give the full
> Oops messages not only the stack trac
On Fri, Feb 14, 2014 at 1:28 AM, Takashi Iwai wrote:
> At Thu, 13 Feb 2014 12:14:58 -0500, Peter Hurley wrote:
> Apparently there's no maintainer but I've cc'ed people who might
> have a clue about this.
Peter ... thanks for pointer.
> On Fri, Feb 14, 2014 at 1:28 AM, Takashi Iwai wrote:
> Is
Can't suspend to ram/disk on the Lenovo X240 with Intel i7-4600.
kernel 3.14.0-rc2
The same kernel works find on Lenovo X230 with Intel i7-3520M.
Here's the trace ..
[] ? do_exit+0x852/0x89d
[] ? prinfk+0x4f/0x54
[] ? oops_end+0x78/0x7d
[] ? no_context+0x1e6/0x1f5
[] ? __do_page_fault+0x348/0x
On Tue, Jun 11, 2013 at 9:51 AM, Al Viro wrote:
> Patch is complete BS and I really wonder what kernel have you observed that
> bug on -
> with mainline on amd64 your example yields
> root@kvm-amd64:~# cat /proc/sys/fs/binfmt_misc/arm
> enabled
> interpreter /usr/bin/qemu-arm-static
> flags:
>
According to Documentation/binfmt_misc.txt, the 'magic' and 'mask' can be
set by echoing it to /proc/sys/fs/binfmt_misc/register.
Here's the problem I can across while working on ARM.
# echo
':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xf
hould not be used anymore. That's to allow
"me" to continue to be able to work on the latest linux-3.10.0-rc1
while waiting for someone to fix those old modules. Reasonable?
Thanks,
Jeff
On Mon, May 13, 2013 at 10:04 AM, Al Viro wrote:
> On Mon, May 13, 2013 at 08:19:46AM +
Anyone on lkml working on patches for vmware to make it run on
Linux-3.10-rc1? The recent change in procfs interface breaks vmware,
diva/eicon and fio modules.
Every modules is now broken and needs to be reworked. Is there a more
subtle way to handle this like give more time to allow developers to
On Wed, Jan 9, 2013 at 1:24 AM, Linus Torvalds
wrote:
> On Tue, Jan 8, 2013 at 9:17 AM, Jeff Chua wrote:
>>
>> Interesting, but there are 54 lines under the kernel directories that
>> use "dma_alloc_coherent(NULL," followed by "dma_free_coherent(NULL,
On Wed, Jan 9, 2013 at 12:39 AM, Linus Torvalds
wrote:
> On Tue, Jan 8, 2013 at 7:51 AM, Jeff Chua wrote:
>> No response so far ... I'm sure someone know this stuff ... Thanks, Jeff.
>>
>> I'm trying to understand how this oops in the diva driver and it's
On Sun, Dec 16, 2012 at 9:53 AM, Al Viro wrote:
> On Sun, Dec 16, 2012 at 09:39:01AM +0800, Jeff Chua wrote:
>> On Sun, Dec 16, 2012 at 9:28 AM, Al Viro wrote:
>> > On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
>> >> How should the symbolic links
On Sun, Dec 16, 2012 at 9:39 AM, Jeff Chua wrote:
> On Sun, Dec 16, 2012 at 9:28 AM, Al Viro wrote:
>> On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
>>> How should the symbolic links be setup to compile the latest kernel?
>>>
>>>
>>> Cur
On Sun, Dec 16, 2012 at 9:28 AM, Al Viro wrote:
> On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
>> How should the symbolic links be setup to compile the latest kernel?
>>
>>
>> Currently I had these links and kernels compiled fine until 2 days ago.
>
On Thu, Nov 29, 2012 at 2:45 PM, Al Viro wrote:
> On Wed, Nov 28, 2012 at 10:37:27PM -0800, Linus Torvalds wrote:
>> On Wed, Nov 28, 2012 at 10:30 PM, Al Viro wrote:
>> >
>> > Note that sync_blockdev() a few lines prior to that is good only if we
>> > have no other processes doing write(2) (or di
On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka wrote:
> block_dev: don't take the write lock if block size doesn't change
>
> Taking the write lock has a big performance impact on the whole system
> (because of synchronize_sched_expedited). This patch avoids taking the
> write lock if the block
On Wed, Nov 28, 2012 at 11:59 AM, Mikulas Patocka wrote:
>
>
> On Tue, 27 Nov 2012, Jeff Chua wrote:
>
>> On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe wrote:
>> > On 2012-11-27 06:57, Jeff Chua wrote:
>> >> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua
>&g
On Wed, Nov 28, 2012 at 4:33 PM, Jens Axboe wrote:
> On 2012-11-28 04:57, Mikulas Patocka wrote:
>>
>>
>> On Tue, 27 Nov 2012, Jens Axboe wrote:
>>
>>> On 2012-11-27 11:06, Jeff Chua wrote:
>>>> On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe w
On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe wrote:
> On 2012-11-27 06:57, Jeff Chua wrote:
>> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua wrote:
>>> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka
>>> wrote:
>>>> So it's better to slow down mount
Jens,
Limited access now at Incheon Airport. Will try the patch out when I arrived.
Thanks,
Jeff
On 11/27/12, Jens Axboe wrote:
> On 2012-11-27 08:38, Jens Axboe wrote:
>> On 2012-11-27 06:57, Jeff Chua wrote:
>>> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua
>>> wrote
On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua wrote:
> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka wrote:
>> So it's better to slow down mount.
>
> I am quite proud of the linux boot time pitting against other OS. Even
> with 10 partitions. Linux can boot up in just
On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka wrote:
> So it's better to slow down mount.
I am quite proud of the linux boot time pitting against other OS. Even
with 10 partitions. Linux can boot up in just a few seconds, but now
you're saying that we need to do this semaphore check at boot up
On Sat, Nov 24, 2012 at 7:31 AM, Jeff Chua wrote:
> On Sat, Nov 24, 2012 at 6:21 AM, Jeff Chua wrote:
>> On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe wrote:
>>> On 2012-11-22 20:21, Linus Torvalds wrote:
>>>> Doesn't sound like a fsdevel issue since it seems to
On Sat, Nov 24, 2012 at 6:21 AM, Jeff Chua wrote:
> On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe wrote:
>> On 2012-11-22 20:21, Linus Torvalds wrote:
>>> Doesn't sound like a fsdevel issue since it seems to be independent of
>>> filesystems. More like some generi
On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe wrote:
> On 2012-11-22 20:21, Linus Torvalds wrote:
>> Doesn't sound like a fsdevel issue since it seems to be independent of
>> filesystems. More like some generic block layer thing. Adding Jens
>> (and quoting the whole thing)
>>
>> Jens, any ideas? Mo
On Wed, Nov 21, 2012 at 11:46 PM, Jeff Chua wrote:
> On Wed, Nov 21, 2012 at 2:09 AM, Jan Kara wrote:
>> I haven't heard about such problem so far. What filesystem are you using?
>
> I've tried ext2/ext3/ext4/reiserfs/btrfs ... all seems to be slower
> than before
On Wed, Nov 21, 2012 at 2:09 AM, Jan Kara wrote:
> I haven't heard about such problem so far. What filesystem are you using?
I've tried ext2/ext3/ext4/reiserfs/btrfs ... all seems to be slower
than before. Seems to be fs independent.
> Can you quantify 'is slower'? Bisecting would be welcome o
It seems the recent kernel is slower mounting hard disk than older
kernels. I've not bisect down to exact when this happen as it might
already been reported or solved. I'm on the latest commit, but it
doesn't seems to be fixed yet.
commit 3587b1b097d70c2eb9fee95ea7995d13c05f66e5
Author: Al Viro
D
On Tue, Feb 26, 2008 at 4:45 AM, Michael S. Tsirkin
<[EMAIL PROTECTED]> wrote:
On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin"
<[EMAIL PROTECTED]> wrote:
> You mean suspend-to-ram works correctly on your t
On Sun, Feb 24, 2008 at 2:43 AM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> >
>
> > Thanks for testing. Below is the final version of the patch with a
> > changelog
> > etc.
>
> Thanks, applied.
>
> With this, I also find that I dislike th
On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
> On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
> > OK, please have a look at the modified patch below.
>
> All right, I'm fine with it. Now we just need to confirm that it works for
> people..
Looks good. Applied Raf
On Fri, Feb 22, 2008 at 9:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> The fact that you'd started running into problems since we merged this just
> means your platform was taking care of it for you (lucky you) and that we
> have some bugs in the hibernate code that we're just discovering.
On Fri, Feb 22, 2008 at 8:42 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Jeff, can you please test hibernation with the patch I've just sent to
> Jesse
> > (reproduced be
On Fri, Feb 22, 2008 at 8:46 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Your s2ram script is doing your STD also? Seems counterintuitive. Anyway,
> some machines also re-POST the GPU on resume from S3; maybe yours is doing
> that.
It's s2ram to do STR, not STD. Sorry for the confusion. Bu
On Fri, Feb 22, 2008 at 7:45 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Thursday, February 21, 2008 2:11 pm Rafael J. Wysocki wrote:
> > Below is a patch that should work around the issue. Please try it and let
> > me know if it helps.
>
> I ended up applying the below patch instead, so i
On Fri, Feb 22, 2008 at 8:31 AM, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Jeff, can you please test hibernation with the patch I've just sent to Jesse
> (reproduced below for convenience)?
Testing now.
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On Fri, Feb 22, 2008 at 8:23 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Your system (either your distro suspend/resume scripts or your platform) must
> be running the video BIOS at resume time, otherwise it would probably come
> back blank.
But I don't think so, unless acpid is doing just t
On Fri, Feb 22, 2008 at 5:02 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Thursday, February 21, 2008 11:43 am Romano Giannetti wrote:
> > > > Let's try to narrow it down to what the interaction is. Are you using
> > > > something like acpi_sleep=s3_bios or similar?
> > >
> > > No. Not addi
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> On Wednesday, February 20, 2008 4:35 pm Jeff Chua wrote:
> > On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]>
> wrote:
> > > Ok, can you give this patch a try with
On Thu, Feb 21, 2008 at 9:21 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I hope those are just warning that can just be ignored.
>
> Oops again, should be dev->pdev. Silly DRM layer obfuscation.
I was just about to write that the test didn't work. Both std str
hangs even before attempting
On Thu, Feb 21, 2008 at 8:39 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Oops, maybe this should just be pci_choose_state instead.
> And this change should just be reverted (leave it as PCI_D0).
drivers/char/drm/i915_drv.c: In function 'i915_suspend':
drivers/char/drm/i915_drv.c:372: warning:
On Thu, Feb 21, 2008 at 5:37 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> Ok, can you give this patch a try with the 'platform' method? It should at
> least tell us what ACPI would like the device to do at suspend time, but it
> probably won't fix the hang.
I can't get it to compile.
driver
On Feb 21, 2008 2:53 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > So, next I'll try "shutdown" to see if it work. I was using "platform".
> Ok, that would be good to try.
"shutdown" does power down properly. But still green on resume.
> Looks like the AR registers are hosed, which is what I
On Feb 21, 2008 1:50 AM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
> > I would like to know what they're for.
> They're for saving and restoring GPU state across suspend/resume. They're
> particularly useful if your machine doesn't re-POST at resume time. In that
> case your GPU may be totally unin
On Feb 21, 2008 1:52 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Ahh. You're using the BIOS to re-initialize your video, aren't you?
I don't know. Just pure simple "s2ram" without any options.
> Let's try to narrow it down to what the interaction is. Are you using
> something like acpi_slee
On Feb 21, 2008 1:28 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> That said, before you do anything else, try if suspend-to-RAM works.
Linus, guess I missed this part ... so before touch anything, I did
tried suspend-to-ram, and it works on console and in X.
And suspend-to-disk hangs, but I c
On Feb 21, 2008 1:28 AM, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Try suspend-and-resume without X.
Works without those two functions.
> Also, try it on one of the more modern laptops - even *with* X.
Again, still works. Tested on Lenovo X60s.
> Basically, the kernel wants to be able to do
On Feb 21, 2008 1:17 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
>
>
> On Feb 20, 2008 2:19 PM, Jeff Chua
> > I'll try the "idle=poll" to see if that works and will try some printk
Tried "idle=poll" but it has not effect.
Thanks,
Jeff.
--
To unsubscr
On Feb 20, 2008 2:19 PM, Jeff Chua
I'll try the "idle=poll" to see if that works and will try some printk
I don't know what exactly the i915_suspend() and i915_resume() are
supposed to do because it works better without them.
After inserting "return 0;"
On Feb 20, 2008 12:32 PM, Jesse Barnes <[EMAIL PROTECTED]> wrote:
>
> On Tuesday, February 19, 2008 6:28 pm Linus Torvalds wrote:
> > On Tue, 19 Feb 2008, Jesse Barnes wrote:
> > > I found the same poweroff issue on my T61. It turned out to be related
> > > to the C state code disabling interrupts
On Feb 16, 2008 5:00 AM, Greg KH <[EMAIL PROTECTED]> wrote:
> > Also, I've tried CONFIG_DETECT_SOFTLOCKUP=n, but this doesn't fix it either.
>
> Ok, this looks to be something else.
>
> > Here's the last dmesg after suspend-to-disk and hang there...
> >
> > CPU 1 is now offline
> > SMP alternative
On Feb 18, 2008 8:57 AM, Tilman Schmidt <[EMAIL PROTECTED]> wrote:
> Am 16.02.2008 23:37 schrieb Jiri Slaby:
> > On 02/16/2008 09:12 PM, Alan Cox wrote:
> > Try to upgrade to at least lvm 2.02.29 (I guess this is the first version
> > which
> > understands the new sysfs layout).
> I'll have to inv
On Fri, Feb 15, 2008 at 2:59 PM, Greg KH <[EMAIL PROTECTED]> wrote:
> I swear someone else sent this in, but my archives don't show it at all.
> I think the patch below should solve this, but I need someone to test it.
I tested but it doesn't fix the problem for me. May be my problem is
differen
Jozsef, Krzysztof
Have you had a chance to take a look at this missing bit?
Thanks,
Jeff.
On Feb 10, 2008 11:06 PM, Jeff Chua <[EMAIL PROTECTED]> wrote:
>
> On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
> >> On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
> >>
On Feb 13, 2008 3:54 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 12 Feb 2008 22:45:09 +0100 Frans Pop <[EMAIL PROTECTED]> wrote:
>
> > Symptom is that the system shuts down normally and completely, it just does
> > not power off.
>
> I've been struggling with an identically-manifesting r
On Feb 5, 2008 9:47 PM, Patrick McHardy wrote:
On Feb 5, 2008 4:16 PM, Jozsef Kadlecsik wrote:
Patrick, I suppose you need a patch against the latest git, don't you?
Yes, please. I'll take you first patch for -stable though if you
send me a Signed-off-by: line.
Please note the lastest git com
On Feb 7, 2008 11:23 AM, <[EMAIL PROTECTED]> wrote:
> Odd, I thought the help text was originally far more helpful, including
> a url. The message isn't telling you you need a kernel module, but that
> you are using an old libcap. It isn't a real problem right now if
> you're not using the SMAC
On Feb 6, 2008 7:40 PM, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> >warning: `named' uses 32-bit capabilities (legacy support in use)
> Yes it is a really interesting case I have seen before,
> but did not bother to investigate.
> CONFIG_SECURITY=y
> CONFIG_SECURITY_CAPABILITIES=m or y
Tried, bu
On Feb 6, 2008 4:13 PM, Jeff Chua <[EMAIL PROTECTED]> wrote:
> Latest linux git complained about this ...
>
> named: capset failed: Operation not permitted: please ensure that the
> capset kernel module is loaded. see insmod(8)
How this started was that with the latest git
Latest linux git complained about this ...
named: capset failed: Operation not permitted: please ensure that the
capset kernel module is loaded. see insmod(8)
Where is the capset kernel module?
Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Feb 5, 2008 4:17 AM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
Actively closed connections are not handled properly, i.e. the initiator
of the active close should not be taken into account. So could you give
a try to the patch below? Does it just suppress the 'invalid packed
ignored' an
On Feb 4, 2008 11:36 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> great! I've added:
> you did all the hard work by bisecting it down so fast - fixing it was
> easy :)
Ingo,
Took me the whole of Friday night. I thought it was just me and my
vmware, so I didn't bother reporting until Jan reported
On Feb 4, 2008 10:53 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > commit 8d947344c47a40626730bb80d136d8daac9f2060
> > Author: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
> > Date: Wed Jan 30 13:31:12 2008 +0100
> >
> > x86: change write_idt_entry signature
>
> does the patch below ontop o
On Feb 4, 2008 7:51 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > sad to say, but f06e4ec... breaks booting the kernel in vmware
> > commit f06e4ec1c15691b0cfd2397ae32214fa36c90d71
I had the same problem. But I bisect down to a earlier commit.
Reverting this patch, and I can boot up using vmware
On Feb 2, 2008 10:44 PM, Jozsef Kadlecsik <[EMAIL PROTECTED]> wrote:
> Could I ask you to make two another tests? (I have been unable to
> reproduce the bug so far, but it must be my fault.)
You need to send more than 510 jobs to see the problem.
> In both cases enable loggin invalid messages as
On Jan 31, 2008 11:25 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Actually its probably the SYN/ACK that is dropped. Please try whether
>
> modprobe ipt_LOG
> echo 255 >/proc/sys/net/netfilter/nf_conntrack_log_invalid
On the good run, I don't get any message, which is good.
On the bad run,
On Jan 31, 2008 10:41 AM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Thanks. In the dump we can see that connections reusing ports
> always have their first SYN dropped and retransmissted three
> seconds later. I'm not sure whats causing this yet, do you have
> any firewall rules that affect loo
On Jan 30, 2008 9:47 PM, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> A binary dump would be more useful:
>
> tcpdump -i lo -w
>
> and I guess Jozsef also wants "-s 0" so the full packets are included.
Attached. Again, both runs with this command to print ...
for((i=1; i<1001;i++)); do echo $i
2008/1/29 Krzysztof Oledzki <[EMAIL PROTECTED]>:
> Strange. You stated that 2.6.23.12 is OK, however above patch
> was included in 2.6.23.4:
> Are you 100% sure that 2.6.23.12 is OK?
Sorry, my mistake. I had another system on 2.6.23.12 and was not OK,
so I bisected starting from 2.6.23.
git bise
On Jan 28, 2008 7:18 AM, Jeff Chua <[EMAIL PROTECTED]> wrote:
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds af
I'm sending printing jobs to a network printer (it's actually printing
to the localhost simply creating a file), and running this on
Linux-2.6.24 will cause the printing to slow down to 1 print every 3
seconds after printing 500 times.
No such symptoms on 2.6.23.12, or 2.6.20.21.
It's repeatable.
On Dec 1, 2007 8:04 PM, Marvin FourtyTwo <[EMAIL PROTECTED]> wrote:
> > Wonder anyone has a patch for vpnclient-linux-x86_64-4.8.00.0490-k9 for
> > 2.6.24?
>
> look here: http://www.unix-ag.uni-kl.de/~massar/vpnc/
Thanks for the pointer. I'll check it out.
Jeff.
--
To unsubscribe from this list:
On Dec 1, 2007 3:21 AM, Mark Lord <[EMAIL PROTECTED]> wrote:
> I've hacked my copy of VMware-6.01 to work with kernel 2.6.24-rc*,
> and dumped my patches for vmmon and vmnet onto my server at:
Thank you! Now, I one step closer to 2.6.24.
Wonder anyone has a patch for vpnclient-linux-x86_64-4.8.00
On Nov 6, 2007 3:58 PM, Hugh Dickins <[EMAIL PROTECTED]> wrote:
> > running Oracle. It only happens with lots of activities.
>
> It would help everybody if you could get more info on this.
Ok, I'll try to log down the activities when it happens again.
> Give 2.6.24-rc2 a try when it appears, if y
On Nov 6, 2007 2:45 AM, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> 1. We can avoid going back to the page allocator for awhile since we will
> find the almost free slab if the current slab is exhausted.
Does this impact SLAB as well? I'm getting out of memory with kernel
2.6.21, 2.6.22 and 2.
Noticed that CONFIG_ACPI_PROCFS and CONFIG_ACPI_PROC_EVENT are
indicated as depreciated. Does that imply a new acpid is needed to
access /sys instead?
Thanks,
Jeff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordom
On 10/22/07, Frans Pop <[EMAIL PROTECTED]> wrote:
> On Monday 22 October 2007, Alexey Starikovskiy wrote:
> > Frans Pop wrote:
> > > I must say that having these relatively top-level ACPI settings
> > > depending on something that is relatively buried away is not very
> > > intuitive!
That's reall
Just pulled latest linux-2.6, and couldn't get ACPI to detect
ACPI_BATTERY and ACPI_AC.
It seems ACPI POWER_SUPPLY is still missing.
Thanks,
Jeff.
-
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:/
On 9/20/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Thu, 20 Sep 2007, Jeff Chua wrote:
>
> With current -git, I still get the same behavior as with
> previous 2.6.23-rcX kernels - i.e. after resume (with
> acpi_sleep=s3_bios,s3_mode), I get corrupted image resembling the
On 9/20/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
> With your patch applied, I get no video at all after resume (I tried all
> three possible combinations of acpi_sleep parameter).
Can you please try again with 2.6.23-rc7. The patch is already
included in -rc7 and it works for me on Lenono X60s.
On 9/14/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Pavel, want to look at the patch before sending it to Linus?
>
> [acpi] Correct the decoding of video mode numbers in wakeup.S
HPA,
After a day, still works, no video mess-up after s2ram resume. I guess
we can close this regression for -
1 - 100 of 240 matches
Mail list logo
