Re: bcm43xx regression in 2.6.24 (with patch)

[Xavier Bestel]

On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote:
> [1] bcm43xx is unmaintained. Larry used to be the maintainer until
> he dropped it a few months ago. 

Doesn't that mean that Alexey gets to be the maintainer, as he's the one
patching it ?

Xav


--
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: currently active Linux kernel versions

[Xavier Bestel]

On mar, 2008-02-12 at 22:18 +0100, Ferenc Wagner wrote:
> 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" versions I can depend on for
> >> a more or less critical server, those that have active security
> >> support or receive at least critical bugfixes?  I know about the
> >> 2.6.2[34].y stable git trees, but I wonder how long will those receive
> >> attention (that is, security fixes).  Can I find a written policy
> >> somewhere?
> >
> > The answer is at http://kernel.org/
> 
> Not quite, at least I can't find 2.6.23.y there, even though that
> branch seems to be maintained...

Ah yes, sorry.
Maybe you should monitor ftp://ftp.eu.kernel.org/pub/linux/kernel/v2.6/
then.

Xav


--
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: currently active Linux kernel versions

[Xavier Bestel]

Hi,

On mar, 2008-02-12 at 21:27 +0100, Wagner Ferenc wrote:
> Hi,
> 
> 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" versions I can depend on for
> a more or less critical server, those that have active security
> support or receive at least critical bugfixes?  I know about the
> 2.6.2[34].y stable git trees, but I wonder how long will those receive
> attention (that is, security fixes).  Can I find a written policy
> somewhere?

The answer is at http://kernel.org/

You're welcome,

Xav


--
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: ndiswrapper and GPL-only symbols redux

[Xavier Bestel]

On Wed, 2008-02-06 at 12:50 +0200, Adrian Bunk wrote:
> The Linux kernel is licenced under the GPLv2.
> 
> Ndiswrapper loads and executes code with not GPLv2 compatible
> licences 
> in a way in the kernel that might be considered similar to a GPLv2'ed 
> userspace program dlopen() a dynamic library file with a not GPLv2 
> compatible licence.
> 
> IANAL, but I do think there might be real copyright issues with 
> ndiswrapper. 

There are issue as soon as ndiswrapper loads a proprietary NDIS. But a
system with just ndiswrapper loaded shouldn't be tainted.

Xav


--
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: [Patch 1/1] Nikon D80 usb-storage quirk needs modified, new FW

[Xavier Bestel]

On Tue, 2008-02-05 at 13:43 +0100, Konstantin Kletschke wrote:
> Nikon did update their FW for the Nikon D80 and usb-storage got
> unusable:
[...]
> I relized the unusal_devs.h needs to be adapted to 
> reflect new FW Version, then it works fine again:
> 
> --- linux-2.6.23/drivers/usb/storage/unusual_devs.h_orig2008-02-05 
> 13:33:55.010623616 +0100
> +++ linux-2.6.23/drivers/usb/storage/unusual_devs.h 2008-02-05 
> 13:32:22.926623601 +0100
> @@ -342,7 +342,7 @@
> US_FL_FIX_CAPACITY),
> 
>  /* Reported by Emil Larsson <[EMAIL PROTECTED]> */
> -UNUSUAL_DEV(  0x04b0, 0x0411, 0x0100, 0x0101,
> +UNUSUAL_DEV(  0x04b0, 0x0411, 0x0100, 0x0110,
> "NIKON",
> "NIKON DSC D80",
> US_SC_DEVICE, US_PR_DEVICE, NULL,
> 
> 
> What I wonder is, why are there other examples only reflecting the
> newest Firmware, are older ones also catched?

Maybe you should leave them both here.

Xav


--
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: Kernel Development & Objective-C

[Xavier Bestel]

On Fri, 2007-11-30 at 19:09 +0900, KOSAKI Motohiro wrote:
> > > Has Objective-C ever been considered for kernel development?
> > 
> > Why not C# instead ?
> 
> Why not Haskell nor Erlang instead ? :-D

I heard of a bash compiler. That would enable development time
rationalization and maximize the collaborative convergence of a
community-oriented synergy.



-
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: Kernel Development & Objective-C

[Xavier Bestel]

On Thu, 2007-11-29 at 12:14 +, Ben Crowhurst wrote:
> Has Objective-C ever been considered for kernel development?

Why not C# instead ?


-
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: Relax permissions for reading hard drive serial number?

[Xavier Bestel]

On Thu, 2007-11-29 at 07:13 -0800, Dan Kegel wrote:
> A few years on, Wine has matured to the point where it's
> ready to run quite a few apps, even some protected by Safedisc.
> One sticking point is that apps like Photoshop and probably
> Punkbuster want to retrieve the hard drive's serial number 

So they can't be installed on a network drive ?

Xav


-
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/

How to disable ECC with bootparam ?

[Xavier Bestel]

Hi,

I have replaced my machine with another one which gives many ECC errors.
At first sight they may be pessimistic because memtest (with ECC off)
doesn't find anything (I'm letting run it overnight, I'll see tomorrow
morning if it really didn't find anything).
I'd like to let it run without thoses ECC messages (which slow it down
pretty much), but
- man bootparam doesn't say anything
- my git tree is on that machine, so I can't access it
- I couldn't successfully google for it

Thanks for your help,

Xav


-
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: Coding Style: indenting with tabs vs. spaces

[Xavier Bestel]

Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
> Hi Benny :)
> 
>  * Benny Halevy <[EMAIL PROTECTED]> dixit:
> > I would like to hear peoples opinion about the indentation convention
> > described below that I personally found the most practical with
> > several different editors.
> 
> While I respect you opinion about tabs, I find tab indentation the most
> evil thing ever invented. Even if done right (that is, not indenting
> using a mixture of spaces and tabs), the only advantage is that you save
> a few bytes.

Who cares ?
The only advantage is that people can make tabs as big (or as small) as
they wish. Tabs become "logical indentation". So one's indentation isn't
forced on anotherone's editor.

Xav


-
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: eradicating out of tree modules

[Xavier Bestel]

On Tue, 2007-10-30 at 09:11 -0400, linux-os (Dick Johnson) wrote:
> I'm sure that the majority of Linux users would never acquire
> the 4-board assembly that we use to acquire X-Ray data and
> generate real-time images for the baggage scanners in use
> at the world's major airports. That assembly, containing
> numerous CPUs and other high-speed pipelined stuff would
> cost the user about  US$100,000 so I'm pretty sure that
> are not many takers so it is very unlikely that any modules
> to support it would never get into the mainstream kernel.

As long as you're maintaining them proprely, I don't why.

Xav


-
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: TODO list for kernel beginer?

[Xavier Bestel]

On Wed, 2007-10-24 at 15:09 +0200, jan sonnek wrote:
> Hello,
> where can I find actually TODO list for kernel beginer?
> Many Thanks,

On http://kernelnewbies.org/

Cheers,
Xav


-
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: [PATCH] Intel Manageability Engine Interface driver

[Xavier Bestel]

Hi,

Le lundi 22 octobre 2007 à 13:22 -0400, Anas Nashif a écrit :
> The Manageability Engine Interface (aka HECI) allows applications to 
> communicate with the Intel(R) Manageability Engine (ME) firmware.
> 
> It is meant to be used by user-space manageability applications to
> access ME features such as Intel(R) Active Management Technology,
> Intel(R) Quiet System Technology and ASF.

Could you briefly explain all these terms ?

Thanks,
Xav


-
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: WANTED: kernel projects for CS students

[Xavier Bestel]

On Mon, 2007-10-15 at 18:36 +0200, Philippe Elie wrote:
> > > Increase speed for a build with no updates
> > > ==
> > > On a resonably fast machine with a decent config it takes
> > > roughly 10 seconds to do a make where nothing is updated.
> > > Generating one single Makefile is assumed to speed up things
> > > and will in addition allow a simpler syntax as what is used today
> > > for some of the uglier constructs.
> > > 
> > > Contact: Sam Ravnborg <[EMAIL PROTECTED]>
> > > Difficulty: 5
> > > Language: Perl or C
> > 
> > Isn't make -j 2 or more implemented by running multiple make in sub-dirs ?
> > Parallel make is more and more used even on cheap hardware.
> 
> Errm, I misread what you said, it can be a single Makefile in each sub-dirs

make -j works fine with an unique Makefile, if that's the question.

Xav


-
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: Patch for WindowsMobile5 on Linux Kernel

[Xavier Bestel]

On Tue, 2007-10-09 at 11:32 +0200, Bernd Petrovitsch wrote:
> On Die, 2007-10-09 at 12:20 +0300, Grosjo.net - jom wrote:
> [...]
> > Would it be possible to include the patches (available on www.synce.org)
> > for WindowsMobile5, as most mobile phones are under Window$, and it is
> > very convenient to connect it to the laptop under Linux
> 
> do {
>Test them
>review them
>sent them as patches hereover
>handle feedback
> until(accepted)

FWIW, the patch in question is a one-liner:

--- linux-2.6.22-rc3-orig/drivers/net/usb/rndis_host.c  2007-05-25 
22:55:14.0 -0400
+++ linux-2.6.22-rc3/drivers/net/usb/rndis_host.c   2007-05-27 
17:06:16.0 -0400
@@ -499,8 +499,7 @@
net->hard_header_len += sizeof (struct rndis_data_hdr);
dev->hard_mtu = net->mtu + net->hard_header_len;
 
-   dev->rx_urb_size = dev->hard_mtu + (dev->maxpacket + 1);
-   dev->rx_urb_size &= ~(dev->maxpacket - 1);
+   dev->rx_urb_size = (dev->udev->speed == USB_SPEED_FULL) ? 16384 : 8192;
u.init->max_transfer_size = cpu_to_le32(dev->rx_urb_size);
 
net->change_mtu = NULL;


Xav


-
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: Floating Point Issue

[Xavier Bestel]

On Thu, 2007-09-27 at 12:41 +0100, mahamuni ashish wrote:
> int main()
> {
> float f= 1256.35;
> char ch[4];
> 
> printf("\n1. f : %f",f);
> memset(ch,'\0',strlen(ch) );

Can't work. ch[]'s content is undefined, so strlen(ch) may read anywhere
in memory, and/or memset() write anywhere.

Xav


-
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: Wasting our Bandwidth

[Xavier Bestel]

Le mardi 18 septembre 2007 à 06:29 -0500, Marco Peereboom a écrit :
> Now if they'd fix the copyright message to only mention Reyk all would
> be good. 

All this mess so easily solved ? Too good to be true.

Xav


-
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: r8169: can't send magic packet for Wake-On-Lan

[Xavier Bestel]

On Wed, 2007-09-12 at 23:20 +0200, Francois Romieu wrote:
> Xavier Bestel <[EMAIL PROTECTED]> :
> [...]
> > Err sorry, I mixed up everything ... I'm using *etherwake* to make the
> > WOL magic packet, and ethtool to check the interface options.
> 
> Weird.
> 
> Can you capture the traffic from the receiving (live) r8169 whith
> both senders and specify the kernel version of the sender/receiver ?

Sorry for not following up: the packet arrives correctly to the
receiving host when it's running, the problem is that it doesn't wake
up. As I have changed the switch at the same time (gigabit upgrade)
maybe when the host is powered off the switch doesn't forward the magic
packet ?
I'll dig the old 10/100 hub and try again.

Thanks,
Xav


-
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: r8169: can't send magic packet for Wake-On-Lan

[Xavier Bestel]

Le mardi 11 septembre 2007 à 23:30 +0200, Francois Romieu a écrit :
> Xavier Bestel <[EMAIL PROTECTED]> :
> [...]
> > with the r8169 I can't send a magic packet anymore. I'm using ethtool
> > for that, with the previous one (an rtl8139b) it was working very well.
> > ethtool -D apparently says it could send the packet ok.
> 
> I see no "-D" option in the sources from the git repository of ethtool.
> 
> Where did you find it ?

Err sorry, I mixed up everything ... I'm using *etherwake* to make the
WOL magic packet, and ethtool to check the interface options.

Xav


-
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/

r8169: can't send magic packet for Wake-On-Lan

[Xavier Bestel]

Hi again,

with the r8169 I can't send a magic packet anymore. I'm using ethtool
for that, with the previous one (an rtl8139b) it was working very well.
ethtool -D apparently says it could send the packet ok.
The receiving side hasn't changed (it's an r8169 too), it's setup for
wake-on-lan and is soft-powered-off with ACPI as it should (no change in
config since a few years).

Do I have to set something special on the sending end ?

Thanks,

Xav


-
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: r8169: instant reboot and interface renaming

[Xavier Bestel]

On Tue, 2007-09-11 at 15:32 +0100, Arjan van de Ven wrote:
> this is userspace doing "eth name by MAC address", your new card has a
> different MAC address than your old card, the userspace application
> tries to bind each name uniquely to an ethX name so it keeps eth0 free
> for your old card.
> 
> If you have a RH/Fedora like distribution, you can hack out the mac
> address from the /etc/sysconfig/network-scripts/ifcfg-eth0 file

Thanks, that was it. For those who are interested, under debian
it's /etc/udev/rules.d/z25_persistent-net.rules

> > The other problem I have is, as soon as I do
> > ifconfig eth3 up
> > the machine is rebooting (like if I pressed the reset button).
> > Adding "acpi=noirq" to the boot cmdline seems to solve this, but
> > I wonder if it's the proper
> > solution ?
> 
> it's obviously not the proper solution :)
> it's odd though; it could entirely be a bios bug. you may want to file
> a bug at bugzilla.kernel.org against the acpi component, and make sure
> you include the full dmesg of a boot at least...

OK, filed http://bugzilla.kernel.org/show_bug.cgi?id=9007

Thanks,
Xav


-
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/

r8169: instant reboot and interface renaming

[Xavier Bestel]

Hi,

I just replaced a fast ethernet card with a Realtek 8169 Gigabit
ethernet card on an old DELL Poweredge running debian. I upgraded the
kernel to 2.6.22 but it didn't solve my problems.

At boot, the kernel says:
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
eth0: RTL8169s/8110s at 0xe0848400, 00:1b:2f:2b:b3:b4, IRQ 17

but then eth0 doesn't exist and is renamed to eth3. Does anybody know
why, and how to get it back to eth0 ? There's probably a FAQ on this
somewhere, but I couldn't find it.


The other problem I have is, as soon as I do
ifconfig eth3 up
the machine is rebooting (like if I pressed the reset button).
Adding "acpi=noirq" to the boot cmdline seems to solve this, but I
wonder if it's the proper solution ?


Thanks for your help,

Xav


-
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/

[OT] Re: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)

[Xavier Bestel]

On Mon, 2007-09-03 at 10:06 +0200, Patrick Mau wrote:
> My debian installation has a system cronjob that will perform a resync
> every first Sunday morning at 1:06 AM:
> 
> [EMAIL PROTECTED] cat /etc/cron.d/mdadm
> ...
> 6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -
> le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet
> 
> I did not read the manpage, but my guess is that 'quiet' will suppress
> the mail notification.

Yes, that was it, checkarray leaves traces in the syslog.
Now I'm really ashamed I jumped on my mailer before using what's left of
my braincells. Could I take it back please ?

Thanks,

Xav


-
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/

forget the noise (Re: very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2))

[Xavier Bestel]

On Mon, 2007-09-03 at 09:56 +0200, Xavier Bestel wrote:
> In itself, this event is already strange. But what's even stranger is
> that another guy had the same resync exactely at the same time

That mystery is solved, see /etc/cron.d/mdadm:

# By default, run at 01:06 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
6 1 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ] && 
/usr/share/mdadm/checkarray --cron --all --quiet

Sorry for the noise.

Xav


-
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/

very very strange simultaneous RAID resync on sep 2, 01:06 CEST (+2)

[Xavier Bestel]

Hi,

I have a server running with RAID5 disks, under debian/stable, kernel
2.6.18-5-686. Yesterday the RAID resync'd for no apparent reason,
without even mdamd sending a mail to warn about that:

Sep  2 01:06:01 awak kernel: md: syncing RAID array md0
Sep  2 01:06:01 awak kernel: md: minimum _guaranteed_ reconstruction speed: 
1000 KB/sec/disc.
Sep  2 01:06:01 awak kernel: md: using maximum available idle IO bandwidth (but 
not more than 20 KB/sec) for reconstruction.
Sep  2 01:06:01 awak kernel: md: using 128k window, over a total of 48064 
blocks.
Sep  2 01:06:01 awak kernel: md: delaying resync of md1 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:01 awak kernel: md: delaying resync of md2 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:05 awak kernel: md: md0: sync done.
Sep  2 01:06:05 awak kernel: RAID1 conf printout:
Sep  2 01:06:05 awak kernel:  --- wd:3 rd:3
Sep  2 01:06:05 awak kernel:  disk 0, wo:0, o:1, dev:hda1
Sep  2 01:06:05 awak kernel:  disk 1, wo:0, o:1, dev:hde1
Sep  2 01:06:05 awak kernel:  disk 2, wo:0, o:1, dev:hdc1
Sep  2 01:06:05 awak kernel: md: delaying resync of md2 until md1 has finished 
resync (they share one or more physical units)
Sep  2 01:06:05 awak kernel: md: syncing RAID array md1
Sep  2 01:06:05 awak kernel: md: minimum _guaranteed_ reconstruction speed: 
1000 KB/sec/disc.
Sep  2 01:06:05 awak kernel: md: using maximum available idle IO bandwidth (but 
not more than 20 KB/sec) for reconstruction.
Sep  2 01:06:05 awak kernel: md: using 128k window, over a total of 1384 
blocks.

In itself, this event is already strange. But what's even stranger is
that another guy had the same resync exactely at the same time (all
times are CEST (+0200)):

Sep  2 01:06:01 in22 kernel: md: syncing RAID array md0
Sep  2 01:06:01 in22 kernel: md: minimum _guaranteed_ reconstruction speed: 
1000 KB/sec/disc.
Sep  2 01:06:01 in22 kernel: md: using maximum available idle IO bandwidth (but 
not more than 20 KB/sec) for reconstruction.
Sep  2 01:06:01 in22 kernel: md: using 128k window, over a total of 1003904 
blocks.
Sep  2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:01 in22 kernel: md: delaying resync of md2 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:01 in22 kernel: md: delaying resync of md3 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:01 in22 kernel: md: delaying resync of md1 until md0 has finished 
resync (they share one or more physical units)
Sep  2 01:06:01 in22 kernel: md: delaying resync of md2 until md3 has finished 
resync (they share one or more physical units)
Sep  2 01:06:39 in22 kernel: md: md0: sync done.
Sep  2 01:06:39 in22 kernel: md: delaying resync of md2 until md3 has finished 
resync (they share one or more physical units)
Sep  2 01:06:39 in22 kernel: md: syncing RAID array md1
Sep  2 01:06:39 in22 kernel: md: minimum _guaranteed_ reconstruction speed: 
1000 KB/sec/disc.
Sep  2 01:06:39 in22 kernel: md: using maximum available idle IO bandwidth (but 
not more than 20 KB/sec) for reconstruction.
Sep  2 01:06:39 in22 kernel: md: using 128k window, over a total of 7004224 
blocks.
Sep  2 01:06:39 in22 kernel: md: delaying resync of md3 until md1 has finished 
resync (they share one or more physical units)
Sep  2 01:06:39 in22 kernel: RAID1 conf printout:
Sep  2 01:06:39 in22 kernel:  --- wd:2 rd:2
Sep  2 01:06:39 in22 kernel:  disk 0, wo:0, o:1, dev:hda1
Sep  2 01:06:39 in22 kernel:  disk 1, wo:0, o:1, dev:hdb1
(reboot)

I'm still gathering informations (no idea what his disks are, etc.), but
does anyone have the same problem ? Does anyone know where it can come
from (debian trouble, md bug, drive firmware problem, rootkit, ..) and
how I can pinpoint that ?

Thanks,
Xav


-
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: speeding up swapoff

[Xavier Bestel]

On Thu, 2007-08-30 at 16:06 +0200, Helge Hafting wrote:
> Xavier Bestel wrote:
> > On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote:
> >   
> >> If the swap device is full, then there is no need for random
> >> seeks as the swap pages can be read in disk order.
> >> 
> >
> > If the swap file is full, you probably have a machine dead into a swap
> > storm.
> Only if you have enough swap. :-)

Yeah, sure. But these days disk space is cheap and I tend to put too big
swap partitions, and I always regret it later ...

Xav


-
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: speeding up swapoff

[Xavier Bestel]

On Thu, 2007-08-30 at 15:55 +0200, Helge Hafting wrote:
> If the swap device is full, then there is no need for random
> seeks as the swap pages can be read in disk order.

If the swap file is full, you probably have a machine dead into a swap
storm.


-
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: [PATCH 4/5] Net: ath5k, license is GPLv2

[Xavier Bestel]

On Wed, 2007-08-29 at 08:35 -0200, Jiri Slaby wrote:
> On 8/29/07, Johannes Berg <[EMAIL PROTECTED]> wrote:
> > On Tue, 2007-08-28 at 12:00 -0400, Jiri Slaby wrote:
> >
> > > The files are available only under GPLv2 since now.
> >
> > Since the BSD people are already getting upset about (for various
> > reasons among which seem to be a clear non-understanding) I'd suggest
> > changing it to:
> 
> yes, please. Can somebody do it, I'm away from my box.
> 
> > + * Parts of this file were originally licenced under the BSD licence:
> > + *
> > >  * Permission to use, copy, modify, and distribute this software for any
> > >  * purpose with or without fee is hereby granted, provided that the above
> > >  * copyright notice and this permission notice appear in all copies.
> > >  *
> > >  * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
> > WARRANTIES
> > >  * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > >  * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > >  * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > >  * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > >  * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > >  * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > + *
> > + * Further changes to this file since the moment this notice was extended
> > + * are now distributed under the terms of the GPL version two as published
> > + * by the Free Software Foundation 
> >
> > johannes

How about asking for changes to be dual-licenced too ?

Xav


-
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: CFS review

[Xavier Bestel]

On Tue, 2007-08-28 at 07:37 +0300, Al Boldi wrote:
> start gears like this:
> 
>   # gears & gears & gears &
> 
> Then lay them out side by side to see the periodic stallings for
> ~10sec.

Are you sure they are stalled ? What you may have is simple gears
running at a multiple of your screen refresh rate, so they only appear
stalled.

Plus, as said Linus, you're not really testing the kernel scheduler.
gears is really bad benchmark, it should die.

Xav


-
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: USB Key light on/off state depending on mount

[Xavier Bestel]

On Sat, 25 Aug 2007 21:26:09 +0200 (CEST), Guennadi Liakhovetski
<[EMAIL PROTECTED]> wrote:
> On Fri, 24 Aug 2007, Josh Boyer wrote:
> 
>> On 8/24/07, Casey Dahlin <[EMAIL PROTECTED]> wrote:
>> > Most USB keys nowadays have a small LED somewhere inside of them that
>> > lights up when they are plugged in. On a windows box, the key is lit
> up
>> > whenever it is mounted, and as soon as it is unmounted it turns off,
>> > giving a handy physical indicator that the key is safe to remove. On
>> > linux, the light is simply on whenever the key is plugged in.

Windows powers off the USB device on unmount, whereas linus does not.
I think the problem may lie in HAL.

Xav


-
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: [OT] Re: Thinking outside the box on file systems

[Xavier Bestel]

On Mon, 2007-08-20 at 09:21 -0700, Randy Dunlap wrote:
> so enlighten us.  What editor do you use/suggest/push?

Corbet !


-
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: Noatime vs relatime

[Xavier Bestel]

On Fri, 2007-08-10 at 07:26 -0700, Vlad wrote:
> Relatime seems to be wasteful of both IO resources _and_ CPU cycles.
> Instead of performing a single IO operation (as atime does), relatime
> performs at least three IO operations and three CPU-dependent
> operations:
> 
> 1) a read IO operation to find out the old atime
> 2) a read IO operation to find out the old ctime
> 3) a read IO operation to find out the old mtime
> 4) Comparison of "old atime is <= than mtime/ctime"
> 5) Find out current time
> 6) Comparison of "current time minus old atime is > X"

As all [acm]times are stored in the same block (inode), I bet all this
is one single IO, plus some insignificant computation (3 comparisons
plus reading time is really smaller than one block IO).

Xav


-
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: linux USB Device.

[Xavier Bestel]

On Thu, 2007-08-09 at 06:39 +0300, jonatan perry wrote:
> Hello,
> I would like to know who the USB system works under linux, I mean,
> I would like to write a kernel module who will create a virtual USB
> device, so that the kernel will think that a hardware USB device is
> exists, were can I start?

Look at the "usb gadgets" subsystem.

Xav


-
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: Is it time for remove (crap) ALSA from kernel tree ?

[Xavier Bestel]

On Thu, 2007-06-28 at 18:34 +0200, Anton Petrusevich wrote:
> > Please always use Reply-to-All on this list -- subscribers here like to
> > also get personal copies.
> 
> I am not subscribed to linux-kernel, I am reading it on the web.

Then please subscribe just for the time you want to participate to the
discussion.

Xav


-
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: NVidia Driver Support - 1680x1050 mode

[Xavier Bestel]

On Wed, 2007-06-27 at 05:58 -0700, Marc Perkel wrote:
> Quite frankly, I don't understand why digital LCD
> monitor even have scan rates in the first place. It's
> not a CRT that actually has an electron beam. You
> would thing that it would have a digital interface
> where the computer told the monitor what to draw and
> the monitor deals with it.

That's it. Information is simply the content of the video RAM, given
serially at a certain rate (as the DVI interface is a serial interface
with a fixed rate, you can't redraw the display at 60fps above a certain
pixel quantity).

Xav


-
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: NVidia Driver Support - 1680x1050 mode

[Xavier Bestel]

On Wed, 2007-06-27 at 06:42 -0400, Kyle Moffett wrote:
> > If you're using a DVI cable, ensure it is dual-link.
> 
> Uhh, no;  1680x1050 does not require a dual-link DVI port/cable.

FWIW single-link DVI can do 1920x1200 - for that the X server uses a
"reduced blanking" mode, i.e. the vertical and horizontal retrace
intervals (useless for LCD/TFT anyway, there's no beam to move) are
shortened.

Xav


-
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: Please release a stable kernel Linux 3.0

[Xavier Bestel]

On Thu, 2007-06-21 at 23:49 +0200, Zoltán HUBERT wrote:
> While some of you dislike 
> closed source drivers, the choices "we users" face are:
> - closed source drivers with closed source OS
> - closed source drivers with open source OS
> Please consider that we are living in a REAL world, and not 
> Disney-Land.

Strange, I'm currently using this option:
- open source drivers with open source OS
and I'm sure I'm not living in Disney-Land.

Xav


-
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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Xavier Bestel]

On Thu, 2007-06-14 at 14:40 +0200, Nicolas Mailhot wrote:
> And drm keys are hardware? Nope, they're a string of bytes. Looks like
> software to me.

Apparently that's the single point of contention. Not yet resolved by
the courts, so everybody can brag his own POV.

Xav


-
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: A kexec approach to hibernation

[Xavier Bestel]

On Mon, 2007-06-11 at 11:51 -0400, Jeremy Maitin-Shepard wrote:
> Xavier Bestel <[EMAIL PROTECTED]> writes:
> 
> > On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote:
> >> >> You might claim then that the solution is to simply keep the network
> >> >> driver quiesced or stopped.  But then it is impossible to write the
> >> >> image over the network.  The way to get around this problem is to write
> >> >> the image over the network using a fresh network stack.
> >> 
> >> > Or teach the driver stack about the difference/reset it. Remember that
> >> > even if you get a fresh network stack, you'll still be getting packets
> >> > for the old stack. Getting a new ip (assuming one is available) won't
> >> > stop other connections getting killed, either because we send resets
> >> > from the kexec'd kernel, or because they timeout looking for the old
> >> > ip.
> >> 
> >> I could be mistaken, but I think that bringing up the network interface
> >> with a different IP address would prevent it from reseting existing TCP
> >> connections, because it would never receive the packets for those
> >> existing connections.  
> 
> > That can't work. There are networks where the client must have a fixed
> > IP, or must accept the adress given by dhcp in order to talk to
> > fileservers. And you still have the same mac adress, which may cause
> > problems.
> 
> I wasn't suggesting that using a different IP address would be a general
> solution.  It might be a solution for a few people.
> 
> In general, I'd imagine that most people would not bring up the network
> interface at all, and most of the people that do would bring it up with
> the same IP address, causing some existing TCP connections to possibly
> be reset.
> 
> I think that causing connections to be reset is, however, far better
> than acking packets that are then silently thrown away.

If I were helping you coding I'd suggest to only concentrate on having
your project work on standard filesystems, and then when it works maybe
think about suspending on crypto-over-loop-over-fuse-over-vpn-over-wifi.
But talk is cheap so I'm shutting up. Right now. :)

Xav


-
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: A kexec approach to hibernation

[Xavier Bestel]

On Mon, 2007-06-11 at 11:01 -0400, Jeremy Maitin-Shepard wrote:
> >> You might claim then that the solution is to simply keep the network
> >> driver quiesced or stopped.  But then it is impossible to write the
> >> image over the network.  The way to get around this problem is to write
> >> the image over the network using a fresh network stack.
> 
> > Or teach the driver stack about the difference/reset it. Remember that
> > even if you get a fresh network stack, you'll still be getting packets
> > for the old stack. Getting a new ip (assuming one is available) won't
> > stop other connections getting killed, either because we send resets
> > from the kexec'd kernel, or because they timeout looking for the old
> > ip.
> 
> I could be mistaken, but I think that bringing up the network interface
> with a different IP address would prevent it from reseting existing TCP
> connections, because it would never receive the packets for those
> existing connections.  

That can't work. There are networks where the client must have a fixed
IP, or must accept the adress given by dhcp in order to talk to
fileservers. And you still have the same mac adress, which may cause
problems.

Xav


-
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: [patch 7/8] fdmap v2 - implement sys_socket2

[Xavier Bestel]

On Fri, 2007-06-08 at 20:30 +0100, Alan Cox wrote:
> > To avoid exactly the kind of problem we have now in future: programs
> > relying on specific patterns.
> 
> Which you seem to think is a bad thing, yet is actually a very good thing
> because it means that crashes are repeatable and problems are debuggable
> from end user reports.

You can have both.
Look at malloc(): when you write your program you can't really guess
which address will be returned by a malloc() call, but you know that if
you launch it twice and if it has the same input, malloc()'s behavior is
repeatable so it's debuggable.

Xav


-
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: A kexec approach to hibernation

[Xavier Bestel]

On Tue, 2007-06-05 at 11:34 +0200, Stefan Seyfried wrote:
> On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
> > FWIW, on my old laptop apm beats any kernel solution hands down in terms
> > of speed
> 
> This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
> RAM setups. At least not if you actually use that memory for anything
> including filesystem cache.
> And you simply cannot buy a new machine today that still supports APM suspend
> to disk.

I don't contest that. I just say that technically, an "external kernel"
can suspend/hibernate a laptop very well.

Xav


-
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: A kexec approach to hibernation

[Xavier Bestel]

On Tue, 2007-06-05 at 08:36 +1000, Nigel Cunningham wrote:
> I spent some time, last I think, seriously considering this approach.
> The more I thought about the details, the more I realised that it wasn't
> a viable approach. As I said before, it does indeed sound like a dream
> at first, but once you get into the details, it becomes more and more of
> a nightmare.

>From very far, it looks like apm suspend (i.e. an "external" system
taking control of the computer for hibernation and resuming).
FWIW, on my old laptop apm beats any kernel solution hands down in terms
of speed and robustness. Not that this means anything for kexec-suspend.

Xav


-
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: Sched - graphic smoothness under load - cfs-v13 sd-0.48

[Xavier Bestel]

Le mercredi 23 mai 2007 à 11:22 -0700, Ian Romanick a écrit :
> > I think some people forget that X11 has its own scheduler for graphics
> > operations.
> 
> And in the direct-rendering case, this scheduler is not used for OpenGL.
>  The client-side driver submits rendering commands directly to its
> kernel module.  It is possible that some kernel modules perform some
> sort of scheduling, but none of the open-source drivers implement such a
> thing.

True, but glxgears isn't a pure DRI app: it calls XNextEvent() each time
it refreshes its window (which is quite often).

Xav


-
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: Sched - graphic smoothness under load - cfs-v13 sd-0.48

[Xavier Bestel]

On Wed, 2007-05-23 at 07:23 +0200, Michael Gerdau wrote:
> For me the huge difference you have for sd to the others increases the
> likelyhood the glxgears benchmark does not measure scheduling of graphic
> but something else.

I think some people forget that X11 has its own scheduler for graphics
operations.

Xav


-
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: [RFC] enhancing the kernel's graphics subsystem

[Xavier Bestel]

On Mon, 2007-05-21 at 17:27 +0100, Dave Airlie wrote:
> > What about modifying the existing fbdev API? You could start with
> one
> > fbdev device per CRTC and then add a new IOCTL to control the output
> > device. I haven't seen anything yet that justifies abandoning the
> > existing fbdev API.
> 
> Then you can't aribtrate properly output hooking is a root level
> thing, you cannot allow the user in multiseat to just pick his own
> outputs, if you claim to want a truly flexible interfaces, also the
> crtc->output mappings aren't always simple, there are limitations on
> most hw about which crtc can map to which output and when you can
> clone etc.. putting policy for this stuff in-kernel would heavily
> restrict what the user can do...

Policy for this kind of thing should just go in HAL's ConsoleKit:
http://lists.freedesktop.org/archives/hal/2007-January/007111.html

Xav


-
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: tracking down disk spinups.

[Xavier Bestel]

Le lundi 14 mai 2007 à 12:24 -0700, Jeremy Fitzhardinge a écrit :
> I don't think you can change filesystem types with remount.  Doesn't
> that just change flags on an existing mount? 

+1


-
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: tracking down disk spinups.

[Xavier Bestel]

Le lundi 14 mai 2007 à 14:57 -0400, Dave Jones a écrit :

> (14:49:52:[EMAIL PROTECTED]:~)# mount
> /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
> (14:49:56:[EMAIL PROTECTED]:~)# mount /dev/mapper/VolGroup00-LogVol00 / -t 
> ext2 -o remount,rw
> (14:50:37:[EMAIL PROTECTED]:~)# mount
> /dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
> 
> Why did the kernel ignore what I told it to do ?
> I'm sure it thinks it knows better than me for a reason, but
> I'd like to know what it is.

Are you sure it's the kernel, and not just mount ?
Did you try cat /proc/mounts ?

Xav


-
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: Please revert 5b479c91da90eef605f851508744bfe8269591a0 (md partition rescan)

[Xavier Bestel]

On Thu, 2007-05-10 at 16:51 +0200, Jan Engelhardt wrote:
> >(But Andrew never saw your email, I suspect: "[EMAIL PROTECTED]" is
> probably 
> >some strange mixup of Andrew Morton and Andi Kleen in your mind ;)
> 
> What do the letters kp stand for?

"Keep Patching" ?



-
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: staircase deadline 0.37 backport 2.6.18.8 and 2.6.19.7 & debian sarge/etch kernel availability

[Xavier Bestel]

On ven, 2007-03-30 at 07:39 -0400, Fortier,Vincent [Montreal] wrote:
> Hi all,
>  
> Backports of the staircase deadline cpu scheduler version 0.37 for
> 2.6.18.8 and 2.6.19.7 kernels are available at
> http://linux-dev.qc.ec.gc.ca/.

BTW thanks a lot Vincent, I regularly use your .deb kernels (instead of
compiling them myself) for testing SD & CFS, they're working great !

Xav


-
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: Back to the future.

[Xavier Bestel]

On Thu, 2007-04-26 at 09:56 -0700, Linus Torvalds wrote:
> Once you have that snapshot image in user space you can do anything you 
> want. And again: you'd hav a fully working system: not any degradation 
> *at*all*. If you're in X, then X will continue running etc even after the 
> snapshotting

Won't there be problems if e.g. X tries to write something to its
logfile after snapshot ?

Xav


-
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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

[Xavier Bestel]

On Wed, 2007-04-25 at 18:50 +1000, Nigel Cunningham wrote:
> > (And guess what, it uses APM and suspend is really faster and way more
> > reliable than each kernel implementation I could try).
> 
> If you tried Suspend2 and had problems with reliability, please send me
> logs. I'll do all I can to help. (I have to qualify it a bit, because
> I'm not able to fix drivers, but if it's a Suspend2 issue, tell me and
> I'll fix it).

Does suspend2 work with APM ? After much trying, I think now the ACPI
implementation of my laptop (a vintage Compaq Armada 1700) is busted,
only APM works.

AFAIR the problem with suspend2 was that it didn't poweroff some parts
of the laptop (the led of the wifi pcmcia card was on, and the lcd light
was on too), but that was last year. Kernel's suspend kind of worked but
didn't resume (no reaction on button press). As I tried all this last
year, I may have forgotten some things.
Honestly, I like this laptop when it works flawlessly, so I don't see
many reasons to try *susp* again. I'll do it when I'm bored, just not
today.

Thanks,
Xav


-
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: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy)

[Xavier Bestel]

On Wed, 2007-04-25 at 07:23 +, Pavel Machek wrote:
> > I absolutely detest all suspend-to-disk crap. Quite frankly, I hate the 
> > whole thing. I think they've _all_ caused problems for the "true" suspend 
> > (suspend-to-ram), and the last thing I want to see is three or four 
> 
> Well, it is a bit more complex than that.
> 
> suspend-to-disk is a workaround for
> 
> 'suspend-to-ram eats too much power' (plus some details like
> being able to replace battery).
> 
> suspend-to-ram is a workaround for
> 
> 'idle machine takes way too much power' (plus some details
> like don't spin the disk so that machine is safe to carry).

I think it depends on who you ask. I personally think that suspend-to-
$youchoose is a workaround for the slowness of system startup. I never
turn off my laptop, I just suspend it.

(And guess what, it uses APM and suspend is really faster and way more
reliable than each kernel implementation I could try).

Xav


-
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: VMWare Workstation 6 for debugging Linux Kernel (!)

[Xavier Bestel]

On Fri, 2007-04-20 at 00:46 +0200, roland wrote:

> We just quietly added an exciting feature to Workstation 6.0. I believe it 
> will make WS6 a great tool for Linux kernel development. You can now debug 
> kernel of Linux VM with gdb running on the Host without changing anything in 
> the Guest VM. No kdb, no recompiling and no need for second machine. All you 
> need is a single line in VM's configuration file.

I think qemu has the exact same feature.

Xav


-
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: ZFS with Linux: An Open Plea

[Xavier Bestel]

On Tue, 2007-04-17 at 16:06 +0100, Ricardo Correia wrote:
> Alan Cox wrote:
> > The real test of whether Sun were serious about ZFS being anywhere but
> > Solaris is what they do to license it - they've patented everything they
> > can, and made the code available only under licenses incompatible with
> > other OS products. Their intent is quite clear, and quite sad.
> 
> That is not quite true. They made ZFS available under the CDDL, which is
> an OSI-approved open-source license that is *less* restrictive than the
> GPL. The CDDL doesn't prevent anyone from using the ZFS code in
> combination with code under other licenses.

You are wrong. Please read e.g.

(maybe there are better analysis somewhere, but I don't know where).

Xav


-
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: ZFS with Linux: An Open Plea

[Xavier Bestel]

On Tue, 2007-04-17 at 10:59 -0400, linux-os (Dick Johnson) wrote:
> So, what needs to be done is simply find out the specifications of
> the file-system.

I didn't know that was that simple, great !
So, what do we wait ? (I love that abusive "we")

Xav


-
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: pktsetup and dvd movie

[Xavier Bestel]

On mar, 2007-04-03 at 20:14 +0200, Thomas Meyer wrote:
> On my pc i encounter a strange error:
> the pktsetup is started during system start and set my dvd driver to
> packet writing mode. then i insert a dvd movie and start xine. and
> sometimes xine says that it can't play the dvd. BUT after
> stoping/removing the pktsetup from the dvd drive again, xine plays the
> dvd movie without problems.
> 
> I have no idea were to start! Does anybody encounter a similar error?
> Any ideas? 

Start by upgrading the drive's firmware.

Xav


-
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: RSDL v0.31

[Xavier Bestel]

On Tue, 2007-03-20 at 07:11 +0100, Willy Tarreau wrote:
> I don't agree with starting to renice X to get something usable

X looks very special to me: it's a big userspace driver, the primary
task handling user interaction on the desktop, and on some OS the part
responsible for moving the mouse pointer and interacting with windows is
even implemented as an interrupt handler, and that for sure provides for
smooth user experience even on very low-end hardware. Why not compensate
for X design by prioritizing it a bit ?
If RSDL + reniced X makes for a better desktop than sotck kernel + X, on
all kind of workloads, it's good to know.


-
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: RSDL v0.31

[Xavier Bestel]

On Mon, 2007-03-19 at 12:36 -0400, Mark Lord wrote:
> Xavier Bestel wrote:
> > On Mon, 2007-03-19 at 12:07 -0400, Mark Lord wrote:
> >> Dell notebook, single P-M-2GHz, ATI X300, open source X.org:
> >> (1) build a kernel in one window with "make -j$((NUMBER_OF_CPUS +
> 1))".
> >> (2) try to read email and/or surf in Firefox/Thunderbird.
> >>
> >> Stock scheduler wins easily, no contest.
> > 
> > What happens when you renice X ?
> 
> Dunno -- not necessary with the stock scheduler.

Could you try something like renice -10 $(pidof Xorg) ?

Xav


-
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: RSDL v0.31

[Xavier Bestel]

On Mon, 2007-03-19 at 12:07 -0400, Mark Lord wrote:
> Dell notebook, single P-M-2GHz, ATI X300, open source X.org:
> (1) build a kernel in one window with "make -j$((NUMBER_OF_CPUS + 1))".
> (2) try to read email and/or surf in Firefox/Thunderbird.
> 
> Stock scheduler wins easily, no contest.

What happens when you renice X ?

Xav


-
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: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

On Wed, 2007-03-14 at 04:25 +0100, Gabriel C wrote:
> [EMAIL PROTECTED] wrote:
> > On Mon, 12 Mar 2007 17:38:38 BST, Kasper Sandberg said:
> >   
> >> with latest xorg, xlib will be using xcb internally,
> >> 
> >
> > Out of curiosity, when is this "latest" Xorg going to escape to distros,
> >   
> 
> Already is .. Xorg 7.2+ libx11 build with xcb enabled..

I think the true improvement will come when toolkits (GTK+ & Qt) are
ported to xcb.

Xav


-
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: [ck] Re: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

On Tue, 2007-03-13 at 20:31 +1100, Con Kolivas wrote:
> nice on my debian etch seems to choose nice +10 without arguments contrary to 
> a previous discussion that said 4 was the default. However 4 is a good value 
> to use as a base of sorts.

I don't see why. nice uses +10 by default on all linux distro, and even
on Solaris and HP/UX. So I suspect that if Mike just used "nice lame"
instead of "nice +5 lame", he would have got what he wanted.

Xav


-
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: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

Le mardi 13 mars 2007 à 05:49 +1100, Con Kolivas a écrit :
> Again I think your test is not a valid testcase. Why use two threads for your 
> encoding with one cpu? Is that what other dedicated desktop OSs would do?

One thought occured to me (shit happens, sometimes): as your scheduler
is "strictly fair", won't that enable trivial DoS by just letting an
user fork a multitude of CPU-intensive processes ?

Xav


-
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: [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2

[Xavier Bestel]

On Mon, 2007-03-12 at 20:22 +1100, Con Kolivas wrote:
> On Monday 12 March 2007 19:55, Mike Galbraith wrote:
> > Hmm.  So... anything that's client/server is going to suffer horribly
> > unless niced tasks are niced all the way down to 19?
> 
> Fortunately most client server models dont usually have mutually exclusive 
> cpu 
> use like this X case. There are many things about X that are still a little 
> (/me tries to think of a relatively neutral term)... wanting. :(

I'd say the problem is less with X than with Xlib, which is heavily
round-trip-based. Fortunately XCB (its successor) seeks to be more
asynchronous.

Xav


-
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: [ck] Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

[Xavier Bestel]

On Tue, 2007-03-06 at 09:10 +1100, Con Kolivas wrote:
> Hah I just wish gears would go away. If I get hardware where it runs at just 
> the right speed it looks like it doesn't move at all. On other hardware the 
> wheels go backwards and forwards where the screen refresh rate is just 
> perfectly a factor of the frames per second (or something like that). 
> 
> This is not a cpu scheduler test and you're inferring that there are cpu 
> scheduling artefacts based on an application that has bottlenecks at 
> different places depending on the hardware combination. 

I'd add that Xorg has its own scheduler (for X11 operations, of course),
that has its own quirks, and chances are that it is the one you're
testing with glxgears. And as Con said, as long as glxgears does more
FPS than your screen refresh rate, its flickering its completely
meaningless: it doesn't even attempt to sync with vblank. Al, you'd
better try with Quake3 or Nexuiz, or even Blender if you want to test 3D
interactivity under load.

Xav


-
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: GPL vs non-GPL device drivers

[Xavier Bestel]

On Thu, 2007-02-15 at 18:36 -0600, Scott Preece wrote:
> if the drivers are for devices
> proprietary to their hardware, then they have no real value to anyone
> else. And the drivers MIGHT contain information useful to their actual
> competitors.

Don't you feel like a contradiction in those two sentences ? :)

Xav


-
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: GPL vs non-GPL device drivers

[Xavier Bestel]

On Thu, 2007-02-15 at 21:48 -0800, v j wrote:
> We only get crap because no one here yet knows how to interpret
> proprietary modules loaded into the kernel.

The proprietary modules where only a tiny wrapper is linux-specific and
the rest is cross-platform are in a grey area, yes.
But your modules, written specifically for linux but distributed as
binary-only, are specifically what the people choosing the GPL want to
avoid. They are a derivative work, and are, as such, illegal under the
GPL.

As stated by multiple other people, please consult a lawyer if you want
to be nasty. Or just play by the rules.

Xav


-
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: GPL vs non-GPL device drivers

[Xavier Bestel]

Le jeudi 15 février 2007 à 10:20 -0800, v j a écrit :
> So far I have heard nothing but, "if you don't contribute, screw you."
> All this is fine. Just say so. Make it black and white. Make it
> perfectly clear what is and isn't legal. If we can't load proprietary
> modules, then so be it. It will help everybody if this is out in the
> clear, instead of resorting to stupid half measures like
> EXPORT_SYMBOL_GPL.

Well, it's written in plain english in the GPL, so you can't pretend you
didn't know it.

And then, that was what guaranteed you you could use linux for your
product in the first place. You're being rude denying the same right to
others.

Xav


-
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: GPL vs non-GPL device drivers

[Xavier Bestel]

On Thu, 2007-02-15 at 12:51 +0200, Mohammed Gamal wrote:
> I am still a kernel newbie, and I am still not very much aware about
> the GPL vs. Non-GPL drivers debate. I personally think it'd be better
> that all drivers should be GPL'd but if that's the case, what would be
> the legal position of such vendors as ATI or NVIDIA who supply closed
> source drivers? Would it be illegal to use them?

Yeah, this is a recurrent debate, and the positions are mixed. Linus
said that the nvidia driver isn't developed only for linux but also for
windows, so it's not a true derivative of the kernel, so the GPL doesn't
really apply. But not everyone (I mean core developpers) fully agrees
IIRC.
But that's not the case with VJ's drivers, which are apparently solely
for linux, so should be distributed under the GPL.

Xav


-
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: GPL vs non-GPL device drivers

[Xavier Bestel]

On Wed, 2007-02-14 at 23:28 -0800, v j wrote:
> Open = 3rd party Linux drivers can be loaded. Closed = No third party
> Linux drivers can be loaded.

Then go ahead and use Windows CE or VxWorks. By your silly definition
they are pretty open.

Xav


-
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: GPL vs non-GPL device drivers

[Xavier Bestel]

On Wed, 2007-02-14 at 22:27 -0800, v j wrote:
> You are right. I have not contributed anything to Linux. Except one
> small patch to the MTD code. However, I don't think that is the point
> here. I am perfectly willing to live with the way Linux is today. I am
> telling you as a user that if Linux continues on the current path it
> will become less and less attractive to Embedded Users.

Guess what ? No one cares. If being serious about the GPL means that
free-riders like you, who take and never give back, prefer to go
elsewhere, that's not a problem. No one looses anything.

BTW, the thousands of different predictions "if linux doesn't do X,
it'll never be successful" get old pretty quicly.

Xav


-
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: [PATCH 0 of 4] Generic AIO by scheduling stacks

[Xavier Bestel]

On Tue, 2007-01-30 at 19:02 -0800, Linus Torvalds wrote:
> Btw, this is also something where we should just disallow certain system 
> calls from being done through the asynchronous method. 

Does that mean that doing an AIO-disabled syscall will wait for all in-
flight AIO syscalls to finish ?

Xav


-
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: Bugfixes: PCI devices get assigned redundant IRQs

[Xavier Bestel]

On Fri, 2007-01-26 at 11:50 +0100, Andreas Block wrote:

>   u8 pin, slot;
> - int irq;
> + int irq = 0;

Aren't there platforms for which irq = 0 is a valid irq ?

Xav


-
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: O_DIRECT question

[Xavier Bestel]

Le jeudi 11 janvier 2007 à 07:50 -0800, Linus Torvalds a écrit :
> > O_DIRECT is still crazily racy versus pagecache operations.
> 
> Yes. O_DIRECT is really fundamentally broken. There's just no way to fix 
> it sanely.

How about aliasing O_DIRECT to POSIX_FADV_NOREUSE (sortof) ?

Xav


-
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: OT: character encodings (was: Linux 2.6.20-rc4)

[Xavier Bestel]

Le dimanche 07 janvier 2007 à 21:40 +0100, Jan Engelhardt a écrit :
> >On Sun, 7 Jan 2007 15:05:53 -0500
> >Dave Jones <[EMAIL PROTECTED]> wrote:
> >
> >> If there's something I should be doing when I commit that I'm not,
> >> I'll be happy to change my scripts.  My $LANG is set to en_US.UTF-8
> >> which should DTRT to the best of my knowledge, but clearly, that isn't
> >> the case.
> 
> No, LC_CTYPE defines what charset you use. (I may be wrong, though.)

IIRC LANG is a superset for all LC_* - i.e. if only LANG is defined, it
sets all your locales, but you can individually set the charset, numeric
format, date format, etc.

Xav


-
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: 2.6.19-rc5: grub is much slower resuming from suspend-to-disk than in 2.6.18

[Xavier Bestel]

On Tue, 2007-01-02 at 11:05 +0100, Stefan Seyfried wrote:
> On Sat, Dec 16, 2006 at 08:05:24PM +0100, Lee Garrett wrote:
> > Andrey Borzenkov wrote:
> > > [...]
> > >This is rather funny; in 2.6.19-rc5 grub is *really* slow loading kernel 
> > >when I switch on the 
> > >system after suspend to disk. Actually, after kernel has been loaded, the 
> > >whole resuming (up to 
> > >the point I have usable desktop again) takes about three time less than 
> > >the process of loading 
> > >kernel + initrd. During loading disk LED is constantly lit. This almost 
> > >looks like kernel leaves 
> > >HDD in some strange state, although I always assumed HDD/IDE is completely 
> > >reinitialized in this 
> > >case.
> > > [...]
> > 
> > I had the same problem (/boot on reiserfs, grub hanging for ages after 
> > resume
> > with 2.6.19), but in 2.6.19.1 it seems fixed. Do you still have this bug,
> > Andrey? I didn't find an update on this issue on LKML.
> 
> I'm pretty sure this is just a coincidence, an issue about how the kernel
> image is actually layed out on your filesystem. I don't think it actually
> has to do anything with the version.

Isn't the cause just that with that kernel the fs image is left unclean,
and grub has to replay the journal, which is slow ? 

Xav

-
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: GPL only modules [was Re: [GIT PATCH] more Driver core patches for 2.6.19]

[Xavier Bestel]

On Wed, 2006-12-13 at 20:15 -0800, Linus Torvalds wrote:
> That said, I'm going to suggest that you people talk to your COMPANY 
> LAWYERS on this, and I'm personally not going to merge that particular 
> code unless you can convince the people you work for to merge it first.

That's quoting material :) Who's your master, by Linus.

-
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: Nokia E61 and the kernel BUG at mm/slab.c:594

[Xavier Bestel]

On Tue, 2006-12-12 at 12:16 +0100, Oliver Neukum wrote:
> Am Dienstag, 12. Dezember 2006 11:28 schrieben Sie:
> > On Tue, 2006-12-12 at 11:44 +0200, Muli Ben-Yehuda wrote:
> > 
> > > I assume the previous crash was 2.6.19 with SMP? did it work with
> > > earlier kernels?
> > 
> > It happens to me as well, current Fedora 6 update
> > kernel-2.6.18-1.2849.fc6.i686 UP, with a Nokia E70 in "PC Suite" mode.
> 
> What functions does this mode involve?

Something like OBEX-over-USB

Xav

-
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: [ANNOUNCE] git-pasky-0.3

[Xavier Bestel]

Le mercredi 13 avril 2005 à 09:48 -0700, H. Peter Anvin a écrit :
> Xavier Bestel wrote:
> > On a related note, maybe kernel.org should host .torrent files (and
> > serve them) for the kernel git repository. That would ease the pain.
> > 
> 
> /me inflicts major bodily harm on Xav.
> 
> There is a reason we (kernel.org) doesn't touch Bittorrent: for a 
> variety of reasons, Bittorrent doesn't lend itself very well to 
> automation.  Jeff Garzik and I have been sketching on a sane replacement 
> for Bittorrent with the working name "Software Distribution Protocol", 
> but it's not even vaporware so far.

Aah, technical details ... glad to hear that, though.

Xav


-
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: Re: [ANNOUNCE] git-pasky-0.3

[Xavier Bestel]

Le mercredi 13 avril 2005 Ã 10:25 +0100, David Woodhouse a Ãcrit :
> On Wed, 2005-04-13 at 10:59 +0200, Petr Baudis wrote:
> > Theoretically, you are never supposed to share your index if you work
> > in fully git environment. 
> 
> Maybe -- if we are prepared to propagate the BK myth that network
> bandwidth and disk space are free. 

On a related note, maybe kernel.org should host .torrent files (and
serve them) for the kernel git repository. That would ease the pain.

Xav


-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Xavier Bestel]

Le jeudi 07 avril 2005 Ã 10:32 +0200, Olivier Galibert a Ãcrit :
> On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> > Le jeudi 07 avril 2005 Ã 10:04 +0200, David Schmitt a Ãcrit :
> > 
> > > Then I would like to exercise my right under the GPL to aquire the source 
> > > code 
> > > for the firmware (and the required compilers, starting with genfw.c which 
> > > is 
> > > mentioned in acenic_firmware.h) since - as far as I know - firmware is 
> > > coded 
> > > today in VHDL, C or some assembler and the days of hexcoding are long 
> > > gone.
> > 
> > VHDL is a hardware description language. You don't code firmware in
> > VHDL.
> 
> If the firmware, or part of it, is uploaded to a fpga you do (or
> Verilog instead of VHDL, same difference).

Oh yes, I was dense. 

Xav


-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Xavier Bestel]

Le jeudi 07 avril 2005 Ã 10:04 +0200, David Schmitt a Ãcrit :

> Then I would like to exercise my right under the GPL to aquire the source 
> code 
> for the firmware (and the required compilers, starting with genfw.c which is 
> mentioned in acenic_firmware.h) since - as far as I know - firmware is coded 
> today in VHDL, C or some assembler and the days of hexcoding are long gone.

VHDL is a hardware description language. You don't code firmware in
VHDL.

Xav


-
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: Documentation/i386/IO-APIC.txt (Re: 2.6.11 USB broken on VIA computer (not just ACPI))

[Xavier Bestel]

Le mercredi 16 mars 2005 Ã 11:00 +0100, Xavier Bestel a Ãcrit :
> Le mardi 15 mars 2005 Ã 21:54 -0800, Andrew Morton a Ãcrit :
> > You may be able to set the thing up by hand with the help of
> > Documentation/i386/IO-APIC.txt.
> 
> There's something I don't get in this document's ascii-art:
> 
> 8<--
>,-.,-.,-.,-.,-.
>  PIRQ4 | |-.,-| |-.,-| |-.,-| || |
>|S|  \  /  |S|  \  /  |S|  \  /  |S||S|
>  PIRQ3 |l|-. `/---|l|-. `/---|l|-. `/---|l||l|
>|o|  \/|o|  \/|o|  \/|o||o|
>  PIRQ2 |t|-./`|t|-./`|t|-./`|t||t|
>|1| /\ |2| /\ |3| /\ |4||5|
>  PIRQ1 | |-  `| |-  `| |-  `| || |
>`-'`-'`-'`-'`-'
> 
> every PCI card emits a PCI IRQ, which can be INTA,INTB,INTC,INTD:
> 
>,-.
>  INTD--| |
>|S|
>  INTC--|l|
>|o|
>  INTB--|t|
>|x|
>  INTA--| |
>`-'
> 
> These INTA-D PCI IRQs are always 'local to the card', their real meaning
> depends on which slot they are in. If you look at the daisy chaining diagram,
> a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of
> the PCI chipset. [...]
> 8<--
> 
> If I follow the wire from Slot4's INTA, I'm ending on PIRQ4 whereas the
> doc says IRQ2. Do I need glasses, or a new fixed-font ?

Sorry for replying to myself, in fact it seems like somebody reversed
the order of PIRQ[1-4] and INT[A-D] in the ascii-art, but didn't touch
the rest of the text at all. There are several more references to a
"reversed order".

Xav


-
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/

Documentation/i386/IO-APIC.txt (Re: 2.6.11 USB broken on VIA computer (not just ACPI))

[Xavier Bestel]

Le mardi 15 mars 2005 Ã 21:54 -0800, Andrew Morton a Ãcrit :
> You may be able to set the thing up by hand with the help of
> Documentation/i386/IO-APIC.txt.

There's something I don't get in this document's ascii-art:

8<--
   ,-.,-.,-.,-.,-.
 PIRQ4 | |-.,-| |-.,-| |-.,-| || |
   |S|  \  /  |S|  \  /  |S|  \  /  |S||S|
 PIRQ3 |l|-. `/---|l|-. `/---|l|-. `/---|l||l|
   |o|  \/|o|  \/|o|  \/|o||o|
 PIRQ2 |t|-./`|t|-./`|t|-./`|t||t|
   |1| /\ |2| /\ |3| /\ |4||5|
 PIRQ1 | |-  `| |-  `| |-  `| || |
   `-'`-'`-'`-'`-'

every PCI card emits a PCI IRQ, which can be INTA,INTB,INTC,INTD:

   ,-.
 INTD--| |
   |S|
 INTC--|l|
   |o|
 INTB--|t|
   |x|
 INTA--| |
   `-'

These INTA-D PCI IRQs are always 'local to the card', their real meaning
depends on which slot they are in. If you look at the daisy chaining diagram,
a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of
the PCI chipset. [...]
8<--

If I follow the wire from Slot4's INTA, I'm ending on PIRQ4 whereas the
doc says IRQ2. Do I need glasses, or a new fixed-font ?

Xav


-
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/

[TROLL] binary drivers and development

[Xavier Bestel]

Le jeudi 10 mars 2005 à 11:28 -0500, John Richard Moser a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I've been looking at the UDI project[1] and thinking about binary
> drivers and the like, and wondering what most peoples' take on these are
> and what impact that UDI support would have on the kernel's development.
[...]

Eh, nice troll ! You made a handful people react :)

Maybe there should be an explicit FAQ entry on what's the take on binary
modules.

Xav


-
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: 2.6: drivers/input/power.c is never built

[Xavier Bestel]

Le samedi 19 février 2005 à 00:51 +0100, Oliver Neukum a écrit :

> > Well, we can say that userspace definitely is interested in "power"
> > key ;-).
> 
> I wouldn't call that selfevident. The system might be eg. a ticket
> vending system and we care only about wake ups from touchscreen,
> trackball and modem and about volume control keys. I don't think
> you can make up any rules about what user space is interested or not.

If noone can tell in advance who will be interested and what to do with
it, that looks like a very good reason to go through userspace ..

Xav


-
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: Re: Reading Bad DVD Under 2.6.10 freezes the box.

[Xavier Bestel]

Le lundi 07 fÃvrier 2005 Ã 09:17 -0500, Justin Piszcz a Ãcrit :
> Yeah, I can try 2.4.29 later tonight; also, the DVD is not scratched, just 
> formatted with Joilet/ISO instead of UDF (which is what should be used on 
> DVDs).
> 
> However, dd if=/dev/hdh of=file.img
>   Even with bs=1 for 1 byte at a time, there seems to be no way to
>   get the data off, however...
> 
>   With the dd, last time I tried it, it just fails.
>   When I use cp to try and copy the file, it freezes the machine.

Does it work with ide-scsi ?

Xav


-
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: Reading Bad DVD Under 2.6.10 freezes the box.

[Xavier Bestel]

Le lundi 07 fÃvrier 2005 Ã 08:05 -0500, linux-os a Ãcrit :

> > Main Question >> Why does Linux 'freeze up' when W2K gives a BadCRC error 
> > msg 
> > (never freezes)?
> 
> Of course it should not. However, there were many incomplete changes
> made in 2.6.nn and some may involve problems with locking, etc.

I don't remember a version of the kernel gracefully handling scratched
CD/DVD.

Xav


-
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: [RFC] Reliable video POSTing on resume (was: Re: [ACPI] Samsung P35, S3, black screen (radeon))

[Xavier Bestel]

Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit :
> Doing this in user space lets you have two reset
> programs, vm86 and emu86 for non-x86 machines.

Perhaps only emu86 should be used, to have a well-debugged codepath on
all archs (amd64, ppc, ...)
As it's usermode, the code size is less of a problem.

Xav


-
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: Accelerated frame buffer functions

[Xavier Bestel]

Le mercredi 02 fÃvrier 2005 Ã 15:21 +0100, Haakon Riiser a Ãcrit :

> How can I use a frame buffer driver's optimized copyarea, fillrect,
> blit, etc. from userspace?  The only way I've ever seen anyone use
> the frame buffer device is by mmap()ing it and doing everything
> manually in the mapped memory.  I assume there must be ioctls for
> accessing the accelerated functions, but after several hours of
> grepping and googling, I give up. :-(

Did you try DirectFB ?

Xav


-
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/

[Oops] 2.6.10: PREEMPT SMP

[Xavier Bestel]

Hi,

I just got this Oops with 2.6.10 (debian/sid stock kernel).

Kernel is tainted by VMWare, but it wasn't used (machine powered on
remotely and used just to run gaim though ssh). I can perhaps try to
reproduce it without it though if you need.

Xav

Jan 31 14:08:01 bip kernel: c01c1447
Jan 31 14:08:01 bip kernel: PREEMPT SMP
Jan 31 14:08:01 bip kernel: Modules linked in: vmnet vmmon ipv6 lp thermal fan 
button processor ac battery nfs lockd sunrpc eth1394 af_packet eepro100 e100 
ohci1394 ieee1394 snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec 
snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc 
gameport uhci_hcd usbcore pci_hotplug
via_agp agpgart parport_pc parport floppy pcspkr rtc ext2 reiserfs tsdev 
mousedev evdev capability commoncap ide_cd cdrom psmouse via686a eeprom 
i2c_sensor i2c_isa i2c_viapro i2c_core 8139too mii ext3 jbd mbcache ide_generic 
via82cxxx trm290 triflex slc90e66 sis5513 siimage serverworks sc1200 rz1000 
piix pdc202xx_old opti621 ns87415 hpt366 ide_disk hpt34x generic cy82c693 
cs5530 cs5520 cmd64x atiixp amd74xx alim15x3 aec62xx pdc202xx_new ide_core unix 
fbcon font bitblit vesafb cfbcopyarea cfbimgblt cfbfillrect
Jan 31 14:08:01 bip kernel: CPU:1
Jan 31 14:08:01 bip kernel: EIP:0060:[__rb_rotate_left+7/64]Tainted: P  
VLI
Jan 31 14:08:01 bip kernel: EFLAGS: 00010286   (2.6.10-1-686-smp)
Jan 31 14:08:01 bip kernel: EIP is at __rb_rotate_left+0x7/0x40
Jan 31 14:08:01 bip kernel: eax: f1b8da60   ebx: da7f38e0   ecx: f58864a0   
edx: 
Jan 31 14:08:01 bip kernel: esi: f58864a0   edi: f1b8da60   ebp: c03b17a4   
esp: eaa93ea0
Jan 31 14:08:01 bip kernel: ds: 007b   es: 007b   ss: 0068
Jan 31 14:08:01 bip kernel: Process cron (pid: 8568, threadinfo=eaa92000 
task=f5b65a20)
Jan 31 14:08:01 bip kernel: Stack: c01c154f f58864a0 c03b17a4 da7f38e0 f1b8da6c 
f1b8da60 da7f38e0 c01a6d07
Jan 31 14:08:01 bip kernel:da7f38e0 c03b17a4 eaa93f40 0008 eaa93f4b 
ffea c01a6dfc 0008
Jan 31 14:08:01 bip kernel:  000b 0013  
eaa93f40  f60d20e0
Jan 31 14:08:01 bip kernel: Call Trace:
Jan 31 14:08:01 bip kernel:  [rb_insert_color+143/240] rb_insert_color+0x8f/0xf0
Jan 31 14:08:01 bip kernel:  [key_user_lookup+215/272] 
key_user_lookup+0xd7/0x110
Jan 31 14:08:01 bip kernel:  [key_alloc+92/800] key_alloc+0x5c/0x320
Jan 31 14:08:01 bip kernel:  [keyring_alloc+64/144] keyring_alloc+0x40/0x90
Jan 31 14:08:01 bip kernel:  [alloc_uid_keyring+74/192] 
alloc_uid_keyring+0x4a/0xc0
Jan 31 14:08:01 bip kernel:  [alloc_uid+199/384] alloc_uid+0xc7/0x180
Jan 31 14:08:01 bip kernel:  [set_user+19/144] set_user+0x13/0x90
Jan 31 14:08:01 bip kernel:  [sys_setuid+179/336] sys_setuid+0xb3/0x150
Jan 31 14:08:01 bip kernel:  [sysenter_past_esp+82/117] 
sysenter_past_esp+0x52/0x75



-
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: [OT] Maintainers master list: new idea

[Xavier Bestel]

I have another suggestion for the MAINTAINER list:

Put the filenames/directories the maintainer is responsible of, perhaps
in a hierarchical tree (X maintains usb drivers, Y maintains usb
keyboards, Z maintains usb keyboard from such vendor).
This should be coherent and easily parsable.

This way, someone which has to send several patches can make a little
script which finds the correct maintainers to send its stuff to.
I've already been in that situation, currently it's a pain.

Xav

-
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: VM Requirement Document - v0.0

[Xavier Bestel]

On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote:
> > Well, on a laptop memory and disk bandwith are rarely wasted - they cost
> > battery life.
> 
> Let me comment on this again, having spent a couple of minutes more 
> thinking about it.  Would you be happy paying 1% of your battery life to get 
> 80% less sluggish response after a memory pig exits?

Told like this, of course I agree !

> Also, notice that the scenario we were originally discussing, the off-hours 
> updatedb, doesn't normally happen on laptops because they tend to be 
> suspended at that time.

Suspended != halted. The updatedb stuff starts over when I bring it back
to life (RH6.2, dunno for other distribs)

Xav

-
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: VM Requirement Document - v0.0

[Xavier Bestel]

On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
> Here's an idea I just came up with while I was composing this... along the 
> lines of using unused bandwidth for something that at least has a chance of 
> being useful.  Suppose we come to the end of a period of activity, the 
> general 'temperature' starts to drop and disks fall idle.  At this point we 
> could consult a history of which currently running processes have been 
> historically active and grow their working sets by reading in from disk.  
> Otherwise, the memory and the disk bandwidth is just wasted, right?  This we 
> can do inside the kernel and not require coders to mess up their apps with 
> hints.  Of course, they should still take the time to reengineer them to 
> reduce the cache footprint.

Well, on a laptop memory and disk bandwith are rarely wasted - they cost
battery life.

Xav

-
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: 2.4.5-ac19: hang on IDE DVD read error

[Xavier Bestel]

On 28 Jun 2001 18:13:38 +0200, Xavier Bestel wrote:
> Hi,
> 
> I retested my scratched DVD on 2.4.5-ac19, and the machine still hangs
> (when using drip) after spitting a few errors in the log:
> Jun 28 00:32:55 bip kernel: Info fld=0x1f49e0, Current sd0b:00: sense key Medium 
>Error
> Jun 28 00:32:55 bip kernel: Additional sense indicates Unrecovered read error
> Jun 28 00:32:55 bip kernel:  I/O error: dev 0b:00, sector 8202112
> 
> As I'm under X, I had no chance to try Magic Sysreq. But machine doesn't
> respond on pings.
> A have a Dual PIII, via686b, Hitachi DVD-ROM GD-7500 on builtin IDE
> controler.
> I'm booting with 'noapic acpi=no-idle', more info on demand.

Oh, and I'm using ide-scsi to access my drive.

Xav

-
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/

2.4.5-ac19: hang on IDE DVD read error

[Xavier Bestel]

Hi,

I retested my scratched DVD on 2.4.5-ac19, and the machine still hangs
(when using drip) after spitting a few errors in the log:
Jun 28 00:32:55 bip kernel: Info fld=0x1f49e0, Current sd0b:00: sense key Medium Error
Jun 28 00:32:55 bip kernel: Additional sense indicates Unrecovered read error
Jun 28 00:32:55 bip kernel:  I/O error: dev 0b:00, sector 8202112

As I'm under X, I had no chance to try Magic Sysreq. But machine doesn't
respond on pings.
A have a Dual PIII, via686b, Hitachi DVD-ROM GD-7500 on builtin IDE
controler.
I'm booting with 'noapic acpi=no-idle', more info on demand.

Xav

-
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: VM Requirement Document - v0.0

[Xavier Bestel]

On 28 Jun 2001 14:02:09 +0200, Tobias Ringstrom wrote:

> This would be very useful, I think.  Would it be very hard to classify
> pages like this (text/data/cache/...)?

How would you classify a page of perl code ?

Xav

-
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: VM Requirement Document - v0.0

[Xavier Bestel]

On 26 Jun 2001 20:43:33 -0400, Dan Maas wrote:
> > Windows NT/2000 has flags that can be for each CreateFile operation
> > ("open" in Unix terms), for instance
> >
> >   FILE_ATTRIBUTE_TEMPORARY
> >   FILE_FLAG_WRITE_THROUGH
> >   FILE_FLAG_NO_BUFFERING
> >   FILE_FLAG_RANDOM_ACCESS
> >   FILE_FLAG_SEQUENTIAL_SCAN
> >
> 

We do (nearly) already have O_DIRECT which won't touch cache (alas I
don't think I will read-ahead more)

Xav

-
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: Thrashing WITHOUT swap.

[Xavier Bestel]

On 24 Jun 2001 22:36:25 +0100, Alan Cox wrote:
> > recompiled it yet).  I have a 140 mb swap partition set up but at the time
> > this happened it was OFF.  I was (still am) running X + twm + two xterms
> > 
> > top gives me:
> > mem: 62144k av, 61180k used, 956k free, 0k shrd, 76 buff, 2636 cached
> > swap: 0k av, 0k used, 0k free [as expected]
> 
> Not as expected - 0k used 0k free - you have no swap

That's what he said. *WITHOUT* swap.

Xav
-
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/

IDE read error hangs kernel

[Xavier Bestel]

Hi,

I have a DVD (IDE, using ide-scsi) with read errors, and when reading it
(UDF-mounted or directly with xine) on the read error the drive clicks,
I have an error in the log and, after a while, the kernel hangs.


Here is the (hand-copied) log:

scsi0:  ERROR on channel 0, id 1, lun 0, CDB: Request Sense 00 00 00 40 00
Info fld=0x1f6fa0, Current sd0b:00: sense key Medium Error
Additional sense indicates Unrecovered read error
 I/O error: dev 0b:00, sector 8240768
scsi : aborting command due to timeout : pid 0, scsi 0, channel 0, id 1, lun 0 Read 
(10) 00 00 1f 6f a2 00 00 06 00


Any hint to make this non-fatal ?

Xav

-
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/