inst your pets. You have been warned.
Linus
--
Alexander E. Patrakov
ch is why I suspect
we'll need the new flag, and I'll just take the heat for saying "0 is
now off limits, because it does this thing that a lot of people
dislike".
I 100% agree with that.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
with the
external world - but Willy already said "it seems fishy". However, _if_
it is solved, then we don't need GRND_INSECURE, because solving #2 is
equivalent to magically making secure random numbers always available.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
20.09.2019 03:23, Alexander E. Patrakov пишет:
20.09.2019 02:47, Linus Torvalds пишет:
On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov
wrote:
This already resembles in-kernel haveged (except that it doesn't credit
entropy), and Willy Tarreau said "collect the small entropy
20.09.2019 02:47, Linus Torvalds пишет:
On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov
wrote:
This already resembles in-kernel haveged (except that it doesn't credit
entropy), and Willy Tarreau said "collect the small entropy where it is,
period" today. So, too many people to
, so in my viewpoint, the driver would be a
net win if some mechanism is added that makes it a no-op by default even
if the driver is built-in. E.g. an explicit "enable" parameter, but I am
open to other suggestions, too.
--
Alexander E. Patrakov
From 2836990aff5bc1dab6a4e927304247dae469c774
ed to load at least a part of the random
seed in the boot loader, and that has not been commonly implemented.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
18.09.2019 18:59, Alexander E. Patrakov пишет:
18.09.2019 18:38, Lennart Poettering пишет:
On Di, 17.09.19 19:29, Willy Tarreau (w...@1wt.eu) wrote:
What do you expect these systems to do though?
I mean, think about general purpose distros: they put together live
images that are supposed
priority.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
that's 75% of success stories (found at least one page that is
preserved after the "reboot" command) based on my samples.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
17.09.2019 22:32, Willy Tarreau пишет:
On Tue, Sep 17, 2019 at 07:30:36PM +0200, Lennart Poettering wrote:
On Di, 17.09.19 21:58, Alexander E. Patrakov (patra...@gmail.com) wrote:
I am worried that the getrandom delays will be serialized, because processes
sometimes run one after another
parallelized boot, which may not be the case, especially for
embedded systems that don't like systemd.
--
Alexander E. Patrakov
17.09.2019 18:11, Alexander E. Patrakov пишет:
17.09.2019 17:11, Theodore Y. Ts'o пишет:
There are only two ways out of this mess. The first option is we take
functionality away from a userspace author who Really Wants A Secure
Random Number Generator. And there are an awful lot of programs
erived from a CSPRNG
seeded by a single read from a random source. If that practice were
followed, then it would either result in a duplicate key (which is not
as bad as a factorable one), or in completely unrelated keys.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
appens, and it boots fine.
2. Ted Ts'o invents yet another brilliant ext4 optimization, and it gets
merged.
3. Somebody discovers that the new kernel kills all his processes, up to
and including gnome-session, and that's obviously a regression.
4. Linus is forced to revert (2), nobody wins.
iping your data.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
ight want to return -ENOSYS unconditionally, and create a different
system call with sane flags.
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
14.09.2019 21:52, Linus Torvalds пишет:
On Sat, Sep 14, 2019 at 9:35 AM Alexander E. Patrakov
wrote:
Let me repeat: not -EINVAL, please. Please find some other error code,
so that the application could sensibly distinguish between this case
(low quality entropy is in the buffer
ish between this case
(low quality entropy is in the buffer) and the "kernel is too dumb" case
(and no entropy is in the buffer).
--
Alexander E. Patrakov
smime.p7s
Description: Криптографическая подпись S/MIME
getrandom request "
+ "(%zd bytes): crng not ready",
+ current->comm, count);
+
+ return -EINVAL;
}
return urandom_read(NULL, buf, count, NULL);
}
--
2.23.0
--
Alexander E. Patrakov
re and how do I escalate the bug? What other info (except DMAR dumps
which are already in the bug) is needed?
--
Alexander E. Patrakov
re and how do I escalate the bug? What other info (except DMAR dumps
which are already in the bug) is needed?
--
Alexander E. Patrakov
information about stuck process
Nitpick: this only works only if the "stuck modprobe" bug is 100%
reproducible. Which is not a given. So it is better to collect as much
information about the bug when it is noticed by systemd.
--
Alexander E. Patrakov
--
To unsubscribe from this list: sen
information about stuck process
Nitpick: this only works only if the stuck modprobe bug is 100%
reproducible. Which is not a given. So it is better to collect as much
information about the bug when it is noticed by systemd.
--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line
d Plumbers. I will take
my laptop with me, feel free to see the situation firsthand or try
debugging patches.
--
Alexander E. Patrakov
--
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 h
to XDC2014, LinuxCon Europe and Plumbers. I will take
my laptop with me, feel free to see the situation firsthand or try
debugging patches.
--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
kernel.org
Cc: One Thousand Gnomes
Cc: Oleg Nesterov
Cc: Benjamin Poirier
Cc: Greg Kroah-Hartman
Cc: patra...@gmail.com
Reported-by: "Alexander E. Patrakov"
Signed-off-by: Luis R. Rodriguez
---
drivers/ata/pata_marvell.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/
: linux-kernel@vger.kernel.org
Cc: One Thousand Gnomes gno...@lxorguk.ukuu.org.uk
Cc: Oleg Nesterov o...@redhat.com
Cc: Benjamin Poirier bpoir...@suse.de
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: patra...@gmail.com
Reported-by: Alexander E. Patrakov patra...@gmail.com
Signed-off-by: Luis R
_read+0x50/0xa0
[ 2164.132691] [] system_call_fastpath+0x1a/0x1f
--
Alexander E. Patrakov
--
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
Ple
] [81171170] SyS_read+0x50/0xa0
[ 2164.132691] [81668e16] system_call_fastpath+0x1a/0x1f
--
Alexander E. Patrakov
--
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
2013/6/23 Rafael J. Wysocki :
> Alexander, I've modified patch [3/3] a bit since you have tested it.
> The modifications shouldn't affect the behavior, but if you could re-test it,
> that would be great.
Retested, everything works just as with the previous version of your patch.
--
Al
.
--
Alexander E. Patrakov
--
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/
> [ 52.273816] pci_bus :16: busn_res: [bus 16] is released
>
> Is the re-dock attempt included? It doesn't seem to leave any trace ...
It is, and indeed it left no traces. See the followup when I attached
the result of manually rescanning the bus - you have already commented
on the
] pci_bus :16: busn_res: [bus 16] is released
Is the re-dock attempt included? It doesn't seem to leave any trace ...
It is, and indeed it left no traces. See the followup when I attached
the result of manually rescanning the bus - you have already commented
on the deadlock there.
--
Alexander E
cond
docking, as described in comments #6 - #8 of
https://bugzilla.kernel.org/show_bug.cgi?id=59501
--
Alexander E. Patrakov
--
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://vge
docking, as described in comments #6 - #8 of
https://bugzilla.kernel.org/show_bug.cgi?id=59501
--
Alexander E. Patrakov
--
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
2013/6/17 Alexander E. Patrakov :
> I am not 100% sure that the static key backtrace is the same in all
> cases. However, I do remember that it does appear both in the
> non-hotplug and hotplug cases.
>
> I will retest this after work, i.e. in ~12 hours.
Tried again, fail
2013/6/17 Alexander E. Patrakov patra...@gmail.com:
I am not 100% sure that the static key backtrace is the same in all
cases. However, I do remember that it does appear both in the
non-hotplug and hotplug cases.
I will retest this after work, i.e. in ~12 hours.
Tried again, failed
2013/6/16 Jiang Liu :
> On 06/15/2013 02:42 PM, Alexander E. Patrakov wrote:
>> Both cases work, and exhibit similar backtraces in dmesg. So I am
>> attaching a dmesg only from the first testcase. Please look for "INFO:
>> trying to register non-static key"
2013/6/16 Jiang Liu liu...@gmail.com:
On 06/15/2013 02:42 PM, Alexander E. Patrakov wrote:
Both cases work, and exhibit similar backtraces in dmesg. So I am
attaching a dmesg only from the first testcase. Please look for INFO:
trying to register non-static key and for *ERROR* Memory manager
2013/6/15 Alexander E. Patrakov :
> Note that the snd_hda_intel bug somehow didn't manifest itself today,
> probably because the TV that is connected to the HDMI output of the
> radeon card was off and because Xorg never really tried to use the
> card.
Well, it did. The sympthoms
2013/6/15 Alexander E. Patrakov patra...@gmail.com:
Note that the snd_hda_intel bug somehow didn't manifest itself today,
probably because the TV that is connected to the HDMI output of the
radeon card was off and because Xorg never really tried to use the
card.
Well, it did. The sympthoms
t; + .handler = handle_dock_event_func,
> };
>
> /* Check whether the PCI device is managed by native PCIe hotplug driver */
>
--
Alexander E. Patrakov
--
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/
*/
--
Alexander E. Patrakov
--
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/
surely hit
https://bugzilla.kernel.org/show_bug.cgi?id=59681 and the hda_intel
bug you mentioned in the first mail in this thread.
Note that, for the initial series of patches, I still don't have any
response to the lockdep warnings in
https://lkml.org/lkml/2013/6/13/398
--
Alexander E. Pa
2013/6/14 Jiang Liu (Gerry) :
> On 2013/6/14 10:30, Yinghai Lu wrote:
>>
>> On Thu, Jun 13, 2013 at 7:09 PM, Jiang Liu (Gerry)
>> wrote:
>>>
>>> On 2013/6/14 2:42, Yinghai Lu wrote:
>>>>
>>>>
>>>> On Thu, Jun 13, 2013 at
2013/6/14 Yinghai Lu :
> Is it a regression?
No.
--
Alexander E. Patrakov
--
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
-fed93fff : pnp 00:09
fee0-fee00fff : Local APIC
fee0-fee00fff : reserved
ffd8- : reserved
1-25fdf : System RAM
25fe0-25fff : RAM buffer
You can compare them with other files from
https://bugzilla.kernel.org/show_bug.cgi?id=56531
--
Alexander E.
2013/6/13 Alexander E. Patrakov :
> 2013/6/13 Jiang Liu :
>> Alexander E. Patrakov reports two bugs related to
>> dock station support on Sony VAIO VPCZ23A4R. Actually there are at least
>> four bugs related to Sony VAIO VPCZ23A4R dock support.
>> 1) can't correctly d
2013/6/13 Jiang Liu :
> Use new helper functions to simpilify ACPI dock, acpiphp code.
Not tested yet, just looking at the code
> - /*
> -* TBD: _EJD support.
> -*/
You have removed this comment. Did it become invalid since it has been written?
--
Alexander
?
--
Alexander E. Patrakov
--
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/
2013/6/13 Alexander E. Patrakov patra...@gmail.com:
2013/6/13 Jiang Liu jiang@huawei.com:
Alexander E. Patrakov patra...@gmail.com reports two bugs related to
dock station support on Sony VAIO VPCZ23A4R. Actually there are at least
four bugs related to Sony VAIO VPCZ23A4R dock support.
1
fed9-fed93fff : pnp 00:09
fee0-fee00fff : Local APIC
fee0-fee00fff : reserved
ffd8- : reserved
1-25fdf : System RAM
25fe0-25fff : RAM buffer
You can compare them with other files from
https://bugzilla.kernel.org/show_bug.cgi?id=56531
--
Alexander E. Patrakov
2013/6/14 Yinghai Lu ying...@kernel.org:
Is it a regression?
No.
--
Alexander E. Patrakov
--
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
);
acpiphp_sanitize_bus(bus);
acpiphp_set_hpp_values(bus);
acpiphp_set_acpi_region(slot);
---
The patch helped, thanks. Note: I have tested it together with
pci_move_pcibios_add_bus_down.patch, I don't know yet if
pci_move_pcibios_add_bus_down.patch is needed.
--
Alexander E. Patrakov
, as that would surely hit
https://bugzilla.kernel.org/show_bug.cgi?id=59681 and the hda_intel
bug you mentioned in the first mail in this thread.
Note that, for the initial series of patches, I still don't have any
response to the lockdep warnings in
https://lkml.org/lkml/2013/6/13/398
--
Alexander E
re are no open fds. The mixer
fd will be closed when it gets a -EIO, i.e. after the device goes
away.
If the above understanding is correct, I think that waiting for zero
references should be at least questioned.
--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line "u
2013/6/12 Alexander E. Patrakov :
> 2013/6/12 Jiang Liu :
>> On Wed 12 Jun 2013 12:51:59 AM CST, Alexander E. Patrakov wrote:
>>> In the initially-docked case, it exhibits the following problem: when
>>> I press the undock button, only one PCI device disappears, an
2013/6/12 Alexander E. Patrakov patra...@gmail.com:
2013/6/12 Jiang Liu liu...@gmail.com:
On Wed 12 Jun 2013 12:51:59 AM CST, Alexander E. Patrakov wrote:
In the initially-docked case, it exhibits the following problem: when
I press the undock button, only one PCI device disappears
there are no open fds. The mixer
fd will be closed when it gets a -EIO, i.e. after the device goes
away.
If the above understanding is correct, I think that waiting for zero
references should be at least questioned.
--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line unsubscribe linux
2013/6/12 Jiang Liu :
> On Wed 12 Jun 2013 12:51:59 AM CST, Alexander E. Patrakov wrote:
>> 2013/6/11 Jiang Liu :
>>> Hi Alexander,
>>> This is much more harder issue to resolve. Let's first work around
>>> this
>>> issue and check whether
c = (struct acpiphp_func *)hp_work->context;
> + acpi_scan_lock_acquire();
> _handle_hotplug_event_func(hp_work->handle, hp_work->type,
> hp_work->context);
> + acpi_scan_lock_release();
> kfree(hp_work);
ork = container_of(work, struct acpi_hp_work, work);
> + func = (struct acpiphp_func *)hp_work->context;
> + __handle_hotplug_event_func(hp_work->handle, hp_work->type,
> + hp_work->context);
> kfree(hp_work); /* allocated in handle_hotplug_event_func */
> put_bridge(func->slot->bridge);
> }
> --
> 1.8.1.2
>
--
Alexander E. Patrakov
--
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/
*)hp_work-context;
+ __handle_hotplug_event_func(hp_work-handle, hp_work-type,
+ hp_work-context);
kfree(hp_work); /* allocated in handle_hotplug_event_func */
put_bridge(func-slot-bridge);
}
--
1.8.1.2
--
Alexander E. Patrakov
in handle_hotplug_event_func */
put_bridge(func-slot-bridge);
}
--
Alexander E. Patrakov
--
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
2013/6/12 Jiang Liu liu...@gmail.com:
On Wed 12 Jun 2013 12:51:59 AM CST, Alexander E. Patrakov wrote:
2013/6/11 Jiang Liu liu...@gmail.com:
Hi Alexander,
This is much more harder issue to resolve. Let's first work around
this
issue and check whether other things are OK. The patch below
? balance_pgdat+0x7e0/0x7e0
[ 6168.673108] [] kthread+0xd6/0xe0
[ 6168.673108] [] ? __init_kthread_worker+0x70/0x70
[ 6168.673108] [] ret_from_fork+0x7c/0xb0
[ 6168.673108] [] ? __init_kthread_worker+0x70/0x70
--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line "unsu
] [8107a200] ? __init_kthread_worker+0x70/0x70
--
Alexander E. Patrakov
--
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
.
There is a little problem: the driver doesn't work at all with the "64-bit
kernel and 32-bit userspace" combination.
ioctl32(lms:7759): Unknown cmd fd(0) cmd(c0084800){t:'H';sz:8} arg(ffdfea44) on
/dev/heci
Could you please fix it?
--
Alexander E. Patrakov
--
To unsubscribe from this list: sen
.
There is a little problem: the driver doesn't work at all with the 64-bit
kernel and 32-bit userspace combination.
ioctl32(lms:7759): Unknown cmd fd(0) cmd(c0084800){t:'H';sz:8} arg(ffdfea44) on
/dev/heci
Could you please fix it?
--
Alexander E. Patrakov
--
To unsubscribe from this list: send the line
/pp.c: TmpMod = 32 + QValue -
2*(abs(Src[j+1]-Src[j]));
This did emit a warning, I have already reported it:
https://trac.xiph.org/ticket/1260
And on IRC, they explained that it is a piece of code that never gets called. So
not a hit.
--
Alexander E. Patrakov
-
To unsubscribe from
cannot simplify this. */
+ if (tree_int_cst_sgn (c) == -1)
+{ warning(0, "Unpatched gcc miscompiles this"); break; }
/* FALLTHROUGH */
case NEGATE_EXPR:
if ((t1 = extract_muldiv (op0, c, code, wide_type, strict_overflow_p))
--
Alexander E. Patrakov
-
To
simplify this. */
+ if (tree_int_cst_sgn (c) == -1)
+{ warning(0, Unpatched gcc miscompiles this); break; }
/* FALLTHROUGH */
case NEGATE_EXPR:
if ((t1 = extract_muldiv (op0, c, code, wide_type, strict_overflow_p))
--
Alexander E. Patrakov
-
To unsubscribe from
/pp.c: TmpMod = 32 + QValue -
2*(abs(Src[j+1]-Src[j]));
This did emit a warning, I have already reported it:
https://trac.xiph.org/ticket/1260
And on IRC, they explained that it is a piece of code that never gets called. So
not a hit.
--
Alexander E. Patrakov
-
To unsubscribe from
David Miller wrote:
From: Greg KH <[EMAIL PROTECTED]>
Date: Mon, 19 Nov 2007 18:29:15 -0800
[EMAIL PROTECTED] would be great to have.
Created, enjoy.
It would be nice to have the archives of this list and the nntp interface on
gmane.
--
Alexander E. Patrakov
-
To unsubscrib
David Miller wrote:
From: Greg KH [EMAIL PROTECTED]
Date: Mon, 19 Nov 2007 18:29:15 -0800
[EMAIL PROTECTED] would be great to have.
Created, enjoy.
It would be nice to have the archives of this list and the nntp interface on
gmane.
--
Alexander E. Patrakov
-
To unsubscribe from this list
) (~0U>>1)-1)
#define CDSL_CURRENT((int) (~0U>>1))
--
Alexander E. Patrakov
-
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.ht
) (~0U1)-1)
#define CDSL_CURRENT((int) (~0U1))
--
Alexander E. Patrakov
-
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
Christoph Hellwig wrote:
On Mon, Oct 22, 2007 at 05:27:51PM +0600, Alexander E. Patrakov wrote:
Yes, there is a call to usermodehelper_init() before the initcalls in
do_basic_setup(), this does mean that firmware can be loaded by means of
the old and obsolete /sbin/hotplug mechanism
Christoph Hellwig wrote:
On Mon, Oct 22, 2007 at 04:32:19PM +0600, Alexander E. Patrakov wrote:
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't
be allowed to be built in.
Could you please
is then supposed to start
udevd and load firmware) - but that's too late.
--
Alexander E. Patrakov
-
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 re
is then supposed to start
udevd and load firmware) - but that's too late.
--
Alexander E. Patrakov
-
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
Christoph Hellwig wrote:
On Mon, Oct 22, 2007 at 04:32:19PM +0600, Alexander E. Patrakov wrote:
That's wrong. You can load firmware from the initramfs even if the
driver is built in. There is no valid reason why a driver shouldn't
be allowed to be built in.
Could you please
Christoph Hellwig wrote:
On Mon, Oct 22, 2007 at 05:27:51PM +0600, Alexander E. Patrakov wrote:
Yes, there is a call to usermodehelper_init() before the initcalls in
do_basic_setup(), this does mean that firmware can be loaded by means of
the old and obsolete /sbin/hotplug mechanism
i.org/ath5k/trunk;), or from git.
--
Alexander E. Patrakov
-
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/
/ath5k/trunk;), or from git.
--
Alexander E. Patrakov
-
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/
necke <[EMAIL PROTECTED]>
Edited by Alexander E. Patrakov to fix incorrect output of "kpartx -l"
Signed-off-by: Alexander E. Patrakov <[EMAIL PROTECTED]>
--- a/kpartx/kpartx.c
+++ b/kpartx/kpartx.c
@@ -387,10 +387,10 @@ main(int argc, char **argv){
PROTECTED]
Edited by Alexander E. Patrakov to fix incorrect output of kpartx -l
Signed-off-by: Alexander E. Patrakov [EMAIL PROTECTED]
--- a/kpartx/kpartx.c
+++ b/kpartx/kpartx.c
@@ -387,10 +387,10 @@ main(int argc, char **argv){
slices[j].minor = m
also don't run top that
frequently I cannot be sure its a recent regression.
Try to capture the i/o log with the following command:
strace -o top.log top
This will show for sure whether the kernel gives out incorrect data or
top misinterprets them.
--
Alexander E. Patrakov
-
To unsubs
top that
frequently I cannot be sure its a recent regression.
Try to capture the i/o log with the following command:
strace -o top.log top
This will show for sure whether the kernel gives out incorrect data or
top misinterprets them.
--
Alexander E. Patrakov
-
To unsubscribe from this list
.
--
Alexander E. Patrakov
-
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/
.
--
Alexander E. Patrakov
-
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/
martin f krafft wrote:
also sprach Alexander E. Patrakov <[EMAIL PROTECTED]> [2007.08.23.1730 +0200]:
I am staring at this log message:
kernel: 7.0.0.1:53 L=79 S=0x00 I=39869 F=0x4000 T=64
and I cannot figure out what it's trying to tell me. Could someone
please enlighten me?
Looks lik
martin f krafft wrote:
I am staring at this log message:
kernel: 7.0.0.1:53 L=79 S=0x00 I=39869 F=0x4000 T=64
and I cannot figure out what it's trying to tell me. Could someone
please enlighten me?
Looks like some DNS packet got logged by your firewall rules.
--
Alexander E. Patrakov
martin f krafft wrote:
I am staring at this log message:
kernel: 7.0.0.1:53 L=79 S=0x00 I=39869 F=0x4000 T=64
and I cannot figure out what it's trying to tell me. Could someone
please enlighten me?
Looks like some DNS packet got logged by your firewall rules.
--
Alexander E. Patrakov
martin f krafft wrote:
also sprach Alexander E. Patrakov [EMAIL PROTECTED] [2007.08.23.1730 +0200]:
I am staring at this log message:
kernel: 7.0.0.1:53 L=79 S=0x00 I=39869 F=0x4000 T=64
and I cannot figure out what it's trying to tell me. Could someone
please enlighten me?
Looks like some
ctually remove files from that directory).
Thank you!
--
Alexander E. Patrakov
-
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/
cted to be
released in two months or so, thus a one-year period before moving tarballs
to "Old" should be enough even for stable LFS books (and if we agree on
that, I'll close http://wiki.linuxfromscratch.org/lfs/ticket/2037 as invalid).
Thanks for cooperation.
--
Alexander E. Patrakov
-
months or so, thus a one-year period before moving tarballs
to Old should be enough even for stable LFS books (and if we agree on
that, I'll close http://wiki.linuxfromscratch.org/lfs/ticket/2037 as invalid).
Thanks for cooperation.
--
Alexander E. Patrakov
-
To unsubscribe from this list: send
that directory).
Thank you!
--
Alexander E. Patrakov
-
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/
1 - 100 of 166 matches
Mail list logo
