"Michael Chan" writes:
> On Tue, 2012-10-02 at 18:49 +0200, Ferenc Wagner wrote:
>
>> Going into the opposite direction: I found that Linux 3.6 does not
>> permanently break the SoL console on upping eth0! I'll try to find
>> the commit which (sort of) f
"Michael Chan" writes:
> On Tue, 2012-10-02 at 14:07 +0200, Ferenc Wagner wrote:
>
>> I'm done with bisecting it: the first bad commit is:
>>
>> commit dabc5c670d3f86d15ee4f42ab38ec5bd2682487d
>> Author: Matt Carlson
>> Date: Thu May 19 1
"Michael Chan" writes:
> On Fri, 2012-09-28 at 22:45 +0200, Ferenc Wagner wrote:
>
>> Upgrading the kernel on our HS20 blades resulted in their SoL (serial
>> over LAN) connection being broken. The disconnection happens when eth0
>> (the interface involve
"Michael Chan" writes:
> On Fri, 2012-09-28 at 22:45 +0200, Ferenc Wagner wrote:
>
>> Upgrading the kernel on our HS20 blades resulted in their SoL (serial
>> over LAN) connection being broken. The disconnection happens when eth0
>> (the interface involve
Hi,
Upgrading the kernel on our HS20 blades resulted in their SoL (serial
over LAN) connection being broken. The disconnection happens when eth0
(the interface involved in SoL) is brought up during the boot sequence.
If I later "ip link set eth0 down", then the connection is restored, but
"ip lin
David Chinner <[EMAIL PROTECTED]> writes:
> The xfs inodes are clearly pinned by the dentry cache, so the issue
> is dentries, not inodes. What's causing dentries not to be
> reclaimed? I can't see anything that cold pin them (e.g. no filp's
> that would indicate open files being responsible), so
David Chinner <[EMAIL PROTECTED]> writes:
> On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
>
>> 5 days ago I pulled the git tree (HEAD was
>> 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
>> (the vmsplice fix and the GFS1 exp
David Chinner <[EMAIL PROTECTED]> writes:
> On Sat, Feb 16, 2008 at 12:18:58AM +0100, Ferenc Wagner wrote:
>
>> 5 days ago I pulled the git tree (HEAD was
>> 25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
>> (the vmsplice fix and the GFS1 exp
Hi,
5 days ago I pulled the git tree (HEAD was
25f666300625d894ebe04bac2b4b3aadb907c861), added two minor patches
(the vmsplice fix and the GFS1 exports), compiled and booted the
kernel. Things are working OK, but I noticed that inode usage has
been steadily rising since then (see attached graph,
"Mike Snitzer" <[EMAIL PROTECTED]> writes:
> 2.6.23.x and 2.6.24.x are obviously quite active for [EMAIL PROTECTED]
What is [EMAIL PROTECTED] That sounds promising. The closest I
could find is [EMAIL PROTECTED]
--
Thanks,
Feri.
--
To unsubscribe from this list: send the line "unsubscribe linux
Willy Tarreau <[EMAIL PROTECTED]> writes:
> I would suggest stable - N-1 for most usages. 2.6.24.y is open, 2.6.23.y is
> supposed to be good. The advantage when you proceed like this is that you
> can jump from an older kernel to a more recent one which has already got its
> share of fixes and is
Xavier Bestel <[EMAIL PROTECTED]> writes:
> On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote:
>
>> which are the "currently active Linux kernel versions" at any point in
>> time? The quote is taken from http://lkml.org/lkml/2008/2/11/29.
>> Or more precisely: which are the "stable" version
Hi,
Looking at http://lxr.linux.no/linux/lib/vsprintf.c#L549 (where
vsnprintf in linux/lib/vsprintf.c parses the % format specifier)
suggests that the printk format string in
http://lxr.linux.no/linux/drivers/ide/setup-pci.c#L657 is correct:
printk(KERN_INFO "%s: not 100%% native mode: "
Jean Delvare <[EMAIL PROTECTED]> writes:
> On Mon, 26 Nov 2007 09:29:40 +0100, Wagner Ferenc wrote:
>
>> On the policy side: some files are not applicable to some types of
>> bonds, and return a single linefeed in that case. Except for one
>> single case, which returns 'NA\n'. The patch changes
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Mon, 26 Nov 2007 09:29:40 +0100 Wagner Ferenc <[EMAIL PROTECTED]> wrote:
>
>> Trailing NULs are present in each file under /sys/class/net/*/bonding
>> and also in /sys/class/net/bonding_masters. That is, in every file
>> provided by drivers/net/bondi
David Miller <[EMAIL PROTECTED]> writes:
> From: Wagner Ferenc <[EMAIL PROTECTED]>
> Date: Wed, 21 Nov 2007 23:16:59 +0100
>
>> Hmm, that would warrant nuking all the reference counts on every
>> driver.
>
> That's not true. When packets are in flight, references go
> to the device and the device
Hi!
Under 2.6.23.1, my lsmod output shows this:
$ lsmod | grep tg3
tg3 100580 0
The usage count is zero, even though it drives my two physical
interfaces:
$ ls -l /sys/class/net/eth-gb?/device/driver
lrwxrwxrwx 1 root root 0 2007-11-21 19:58 /sys/class/net/eth-gb1/device/dri
Jiri Slaby <[EMAIL PROTECTED]> writes:
> I meant the creating of a git repository with only the module would be the
> easiest possible and most comfortable way for you :). Otherwise I can post
> you a
> patch serie.
We can go either way, as you prefer.
> On 10/18/2007 11
"Jiri Slaby" <[EMAIL PROTECTED]> writes:
> On 10/16/07, Wagner Ferenc <[EMAIL PROTECTED]> wrote:
>
>> Jiri Slaby <[EMAIL PROTECTED]> writes:
>>
>>> Are you willing to test to-pci-probing patches (i.e. patches which
>>> converts the driver to the model introduced in linux 2.4)?
>>
>> Well yes. We'
Jiri Slaby <[EMAIL PROTECTED]> writes:
>> Start of forwarded message ----
>> From: Ferenc Wagner <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED]
>> Subject: RocketPort Linux driver errors on module reload
>> Date: Fri
/sys/class/tty causing grief on reinsert and
crippling udev.
Assuming it's an easy fix, can I plea for a patch against 2.6.23? Or
is there a workaround like manually deregistering the devices?
Thanks,
Feri.
Start of forwarded message ----
From: Fer
21 matches
Mail list logo
