[Cooker] Re: unable to use bewan drivers with 2.4.22-10mdk

[Juan Quintela]

>>>>> "guillaume" == Guillaume Rousse <[EMAIL PROTECTED]> writes:

Hi

guillaume> Ainsi parlait Juan Quintela :
>> It appears that your are compiling your drivers agaist a wrong source
>> for some reason.  Can you give one address for the drivers, please?
guillaume> You are right, i failed to notice it :-(

guillaume> However, i'd like to know why urpmi kernel-source on a
guillaume> fleshly installed 9.1 download a source different from the
guillaume> installed kernel...

urpmi is a mistery :)

I have no idea why you ended with a non-matching kernel-source &
kernel installed.  Mirror breakage?

guillaume> BTW, and just by curiosity, what could have caused the
guillaume> unresolved symbols to change ?

symbols just got their name depending of:
- kernel-version
- some hash created depending of same config options (i.e. SMP/non SMP
  kernel, high memory/not high memory, ).
- number & type of arguments.

How they are assigned is also a _difficult_ way.  You can look at the
two awk scripts in the kernel source and you will see how difficult it
is to have kernel symbols for several kernels together.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: unable to use bewan drivers with 2.4.22-10mdk

[Juan Quintela]

> "guillaume" == Guillaume Rousse <[EMAIL PROTECTED]> writes:

guillaume> Ainsi parlait Guillaume Rousse :
>> Using latest bewan drivers release (7.4), the modules build correctly, but
>> fails to install as depmod reports unresolved symbols. It works OK with
>> 2.4.21-0.13mdk however.
guillaume> New problem today: the set of unresolved symbols changed. The only change 
was 
guillaume> to remove the PCI card, as i need to keep it on the old gateway until i 
guillaume> succeed building the drivers on the new one. Now it looks for unversioned 
guillaume> symbols, whereas the default mdk kernel uses versioned ones...

-EENOUGHINFO.

It appears that your are compiling your drivers agaist a wrong source
for some reason.  Can you give one address for the drivers, please?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Kernel 2.6 cutover?

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

Hi

svetoslav> :(
svetoslav> so far no one (officialy)  stated anything about 2.6 and mdk-10.0, am i
svetoslav> wrong ?

Humm, I told in previous message what I thought.  But as always, it is
my opinion :)  Not sure what is Mandrake official opinion about the
issue (but I guess it should be near mine :)

svetoslav> me too,
svetoslav> but a lot of external drivers/ features are missing

svetoslav> anyone having url's of projects that are porting their drivers/ features to
svetoslav> 2.6 ?

If someone got that list, I am also interested :)

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Kernel 2.6 cutover?

[Juan Quintela]

> "robert" == Robert Fox <[EMAIL PROTECTED]> writes:

Hi

robert> Just wondering, what is the rough development plan for Cooker?
robert> Specifically, at what stage will the kernel 2.6 series be the focus and
robert> the 2.4 go to contribs?

No.  Just finishing a 2.6 kernel code (based on the one in contribs),
and a 2.4.23-rc1 kernel.

I don't have a crystal ball, but I guess that for 10.0, 2.6 is not
going to be ready for everybody.  My guess is that situation will be
similar to 8.0, where we used 2.2 and 2.4.  Here with 2.4 and 2.6.
For some configurations 2.4 will be better, for other 2.6.

robert> Is it a stated goal that the 2.6 kernel (not withstanding and "critical"
robert> show stopper) will be the main kernel for Mandrake 10.0 (due roughly
robert> next March?)

As I stated, I don't think that it will be ready, but it will be an
option for sure.

robert> The sooner we get kernel 2.6 into the mainstream Cooker - the more
robert> testing will take place . . . or is it too soon?

I hoped to have it ready this week, but bttv + new alsa + new
grsecurity +  in 2.4.23-rc1 took all my energies.  I hope that it
will be there during next week.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: TUX?

[Juan Quintela]

>>>>> "adam" == Adam Williamson <[EMAIL PROTECTED]> writes:

adam> On Sun, 2003-11-02 at 19:26, Juan Quintela wrote:
>> As the "proof is in the pudding", somebody in 2.4 era, created an http

adam> Quick colloquialism fix - actual phrase is "the proof of the pudding is
adam> in the eating". :)

/me returns to his English lessons.

As you can expect my Engilsh lessons show me how to talk about aunt's
cats and gardens, not really _colloquial_ English at all :(



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: packet writing patch for kernel-source

[Juan Quintela]

> "salane" == Salane KIng <[EMAIL PROTECTED]> writes:

salane> Can someone post the correct patch for kernel-source-2.4.22-23mdk or if and 
salane> where it is locate in the -10 sources  . For some of us who dont have LG 
salane> cdroms packet writing is very usefull. I don't wish to be stuck at the -10 
salane> kernel just because of some trash hardware. I have tried to patch it with 
salane> packet-0.0.2o-pre1 but i get install errors. If someone can tell me where it 
salane> is locate in the -10 sources I can hopefully pull it from there and use a 
salane> custom kernel. Why was it pulled from kernel-source It should have been left 
salane> there just as a user compiled option.


Will be back in 24mdk or so.  I think that I know what the problem is
and how to fix it.  But still have to think a bit about the problem.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: TUX?

[Juan Quintela]

> "oden" == Oden Eriksson <[EMAIL PROTECTED]> writes:

Hi

oden> I asked to have TUX included before but it was decided not to use the patch 
oden> because security considerations. But now there's new times with zillions of 
oden> kernels laying around. So, maybe Thomas or some one else would consider 
oden> implementing TUX into a new server oriented kernel?

oden> http://freshmeat.net/branches/45229/

oden> I tried to use the update 9.2 kernel but got rejects, this is simply too time 
oden> consuming for me.

oden> So whatcha say?

As the "proof is in the pudding", somebody in 2.4 era, created an http
sever in user space that was faster than tux (it was named chromium or
something like that).  It was not opensource.  I don't know if
somebody has created/modified an opensource http server to be
faster/as fast as tux.

Later, Juan "Hint Hint" Quintela.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: What is an LG CD-ROM?

[Juan Quintela]

> "evan" == Evan Waite <[EMAIL PROTECTED]> writes:

Hi

evan> Haha, you mean still have horizontal lines (2) across them.  I have a
evan> 19" Dell Trinitron (P992) that is only about a year old and has had the
evan> lines since new.

I have been told that they were real wires to support the re-inforce
the screen.  But I don't know.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: What is an LG CD-ROM?

[Juan Quintela]

> "thierry" == Thierry Vignaud <[EMAIL PROTECTED]> writes:


thierry> actually, unlike crt screens, it's hard to make an lcd screen without
thierry> a few dead pixels (only one dead transistors and ...).
thierry> [ well, on the contrary, high quality crt trinitron screens used to
thierry> have an horizontal line on them ]

There were 2 damned lines.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-source bug in 9.2

[Juan Quintela]

>>>>> "juan" == Juan Quintela <[EMAIL PROTECTED]> writes:

>>>>> "sharrea" == Sharrea Day <[EMAIL PROTECTED]> writes:
sharrea> Hi
sharrea> Not sure if this is the right place to ask/report ??  Is this a bug?

22mdk compiles ok with gcc-2.96.

It is still compiling on cluster (will be in mirrors at the end of today).

Only module that don't compiles in cx88*.  You need to disable it.

23mdk/24mdk will have a --with gcc296 option that will do it
automagically.

Later, Juan.

PS.  Yes, my memory is bad, if you don' tsee it working there, send me
report again :p

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Fwd: Re: Supermount / Zip100 bug

[Juan Quintela]

> "andrey" == Andrey Borzenkov <[EMAIL PROTECTED]> writes:

Hi

andrey> As I do not have hardware nor sufficient knowledge about it I
andrey> hardly can fix it. It appears ide-floppy does not implement
andrey> media change detection at all - the only thing it does is fake
andrey> media change on driver ->open. It means supermount never
andrey> detects any disk change of course.

Ide-floppy is quite bad, it is easier (for some things) to use
ide-scsi for zips.  The things that I remembered were that:
- ide-floppy just locks the drive on open, no way to change that.
- ide-scsi had other problems that I forgot :(

Will take a look.

Later, Juan.

andrey> Anyone could get a look? The right thing is probably add sense code decoding 
andrey> to idefloppy_analyze_error and use some innocent command like TEST_UNIT_READY 
andrey> in idefloppy_media_change.

andrey> what our kernel gurus on cooker say? :)


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: OT: My $firewall is bigger than yours!

[Juan Quintela]

>>>>> "brad" == Brad Felmey <[EMAIL PROTECTED]> writes:

brad> On Tue, 2003-10-28 at 09:02, Juan Quintela wrote:
>> And people told me that my firewall with a Via C3-800 is
>> over-dimensioned :)

brad> LOL!

brad> Mine is a SuperMicro 4U dual 2.4GHz Xeon, 4GB RAM, 500GB RAID5 15k SCSI.
brad> It's kind of a waste, but the box was just an extra lying around.

Noxt time that you have an extra box lying around, just ask for my
mail address :)

/me counts and you have more RAM and more disk that all my machines
combined in that one.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: possible kernel (xfs?) BUG in 9.2 kernels (10mdk/21mdk)

[Juan Quintela]

> "tmb" == Thomas Backlund <[EMAIL PROTECTED]> writes:

tmb> I upgraded my firewall to 9.2 and got into a weird problem :-(
tmb> it's a dual p2-333 with 256mb of ram

And people told me that my firewall with a Via C3-800 is
over-dimensioned :)

[scsi and RAID is used ]

tmb> when the system is installed and has been running for I while...
tmb> it just seems locks up, and does not respond to any keyboard activities,
tmb> and the sad part is I don't have any errors to show ... not in logs, and not 
tmb> on the console... so go figure :-(

that is really strange.  Can you try a serial console?
I use xfs in one of my machines and it is working well.
/me sees reinstalling yet again :p

tmb> When I get home tonight I'll try to boot an up kernel, to see if it's smp 
tmb> related... I'll also try to figure out what's wrong... but for now I just 
tmb> wanted to give preliminary info...

tmb> as for now I reverted to an older kernel of my own:
tmb> 2.4.22-0.5.2tmb_mdksmp

tmb> and it works as it should...

Humm, that is _very_ strange.  xfs should work as expected.

/me stress test an xfs partition in its SMP machine.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-source bug in 9.2

[Juan Quintela]

> "sharrea" == Sharrea Day <[EMAIL PROTECTED]> writes:

sharrea> Hi
sharrea> Not sure if this is the right place to ask/report ??  Is this a bug?

sharrea> Trying to compile a kernel with gcc-2.96 using:
sharrea> kernel-source-2.4.22-18mdk
sharrea> config from current install of kernel-i686-up-4GB-2.4.22.18mdk-1-1mdk
sharrea> Soltek SL-75KAV motherboard
sharrea> AMD Athlon 1GHz
sharrea> 1024 MB SDRAM
sharrea> nVidia 64MB GTS Pro graphics

sharrea> I get the following error:

sharrea> make[1]: Entering directory `/usr/src/linux-2.4.22-18mdk/arch/i386/mm'
sharrea> make all_targets
sharrea> make[2]: Entering directory `/usr/src/linux-2.4.22-18mdk/arch/i386/mm'
sharrea> gcc -D__KERNEL__ -I/usr/src/linux-2.4.22-18mdk/include -Wstrict-prototypes 
sharrea> -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -pipe 
sharrea> -mpreferred-stack-boundary=2 -march=i686   -nostdinc -iwithprefix include 
sharrea> -DKBUILD_BASENAME=init  -c init.c -o init.o
sharrea> init.c:463: parse error before `_Bool'
sharrea> init.c:464: warning: function declaration isn't a prototype
sharrea> init.c: In function `one_highpage_init':
sharrea> init.c:465: `bad' undeclared (first use in this function)
sharrea> init.c:465: (Each undeclared identifier is reported only once
sharrea> init.c:465: for each function it appears in.)
sharrea> init.c:466: `pfn' undeclared (first use in this function)
sharrea> init.c:467: `page' undeclared (first use in this function)
sharrea> init.c:471: `bad_ppro' undeclared (first use in this function)
sharrea> init.c: In function `free_pages_init':
sharrea> init.c:529: `_Bool' undeclared (first use in this function)
sharrea> init.c:529: parse error before `bad'
sharrea> init.c:530: `bad' undeclared (first use in this function)
sharrea> make[2]: *** [init.o] Error 1
sharrea> make[2]: Leaving directory `/usr/src/linux-2.4.22-18mdk/arch/i386/mm'
sharrea> make[1]: *** [first_rule] Error 2
sharrea> make[1]: Leaving directory `/usr/src/linux-2.4.22-18mdk/arch/i386/mm'
sharrea> make: *** [_dir_arch/i386/mm] Error 2

sharrea> Do I need to report this as a bug to MandrakeSoft Bugzilla?
sharrea> I need this kernel compiled with gcc-2.96 for my satellite internet 
sharrea> connection card driver.  Tried the newbie list but nobody seems to know.

g, BadRAM patch again.

22mdk should fix it.

Sorry about it, I didn't test kernel with 2.96.

later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [IMPORTANT] 9.2 install potentially frying some LG cdrom drives

[Juan Quintela]

> "steffen" == Steffen Barszus <[EMAIL PROTECTED]> writes:

>> On Friday 24 October 2003 07:14 am, Guillaume Cottenceau wrote:
>> > Guillaume Cottenceau <[EMAIL PROTECTED]> writes:
>> > > For the moment, it seems it's related to LG CRD-84xx drives.
>> >


steffen> Another Question. Is it safe to install Mdk 9.2 with another drive and 
steffen> have an LG on the machine afterwards ? Or should i wait till a kernel 
steffen> update is out ? I will install 9.2 on a friends machine tomorrow and he 
steffen> as an LG drive too. For install i use sure another drive.

You need at least 21mdk or marcelo kernel for being safe.

Later, Juan.




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: LG Drives

[Juan Quintela]

> "marcel" == Marcel Pol <[EMAIL PROTECTED]> writes:

Hi

marcel> While reading slashdot, I found this comment interesting (yes, that does
marcel> happen on slashdot :-) )
marcel> http://slashdot.org/comments.pl?sid=83579&cid=7310813
marcel> "Why is Linux trying to send a flush cache command to a CD-ROM drive in the
marcel> first place? That's a stupid thing to do. The ATAPI FLUSH CACHE command tells
marcel> the device to flush its write cache to the media. A CD-ROM has no write cache,
marcel> and can't write to any media. Of course, it's even more stupid for a drive to
marcel> self-destruct when it gets a flush cache command..."

marcel> Is this maybe 2 bugs "working together"? Using FLUSH_CACHE where it shouldn't,
marcel> and have the cdrom reading that as UPLOAD_FIRMWARE

Yes. there are two bugs here:

- One, sending FLUSH_CACHE to a CD-ROM drive.  CD-ROM drive decides:
  * do nothing (i.e. it don't have a cache, nothing to do).
  * return an error (Are you stupid, I don't have write capability).
  * return an "unimplemented/unknown command"

Any of the three returns is ok.  The reason of sending a FLUSH_CACHE
for a CDROM is that way, we can share the CD-ROM and CD-RW code for
packet writing.

- Now the big problem:
*  ATAPI spec states that one CDROM not implementing FLUSH_CACHE
  command is ok, but using that command to do anything else is not
  allowed.

- Problem 2:
  Having any kind of modify firmware command that don't test that the
  payload of the command is a firmware by checksum/signature/etc is
  just the more stupid thing that you can do in hardware world.

Later, Juan. 

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: LG Drives

[Juan Quintela]

> "jos" == Jos  <[EMAIL PROTECTED]> writes:

Hi

jos> Yes, it is a firmware bug, and yes, the LG drives are responsible for this. 
jos> But, it is Mandrakes own fault that this happens. 

Yes.  And we are also the cause of all the evil things in the world.

jos> If you take beta / heavy modified kernels instead of kernels that
jos> have been tested by the entire linux community, you can expect
jos> things like these to happen.

yes?  And guess what.  When one new feature is talked about being
integrated into upstream kernel, one of the best ways of backing it is
that it has been included during quite time in distributions, and that
it don't show problems there.

jos> True, strange that this bug was able to tunnel trough all RCs,
jos> but this once again proves that it's better to use the entire
jos> linux community as testers instead of a few beta testers,
jos> i.e. use only stock kernels.

That is good if the functionality of stock kernel is ok for you.
Examples:

- you only use sound for playing some MP3 OSS is ok for you.  If you
  want to do anything interesting with sound, you need ALSA.

- you have a server that is 100km away, you want lm_sensors to read
  the temperatures remotely and detect when fans die.

- you are a company, and you need IPSEC, information as clear text is
  not good enough for you.

- You uses a firewall and thinks that being able to handle IRC
  protocols is a need (until not so far away iptables on kernel
  upstream was not able to tunnel IRC).

- You have new hardware that without ACPI don't works correctly (there
  are hardware like that, specially laptops, and each time more).
  Real ACPI has only been integrated in kernel in 2.4.22.

- You have a nice broadcom network card.  bcm5700 and bcm4400 are a
  lot of times the only drivers supporting your card.

- You think that waiting a lot each time that you start high-IO
  operations is not an option (Andrea VM patches & low latency ones).

- You think that having a CD-RW being able to do more things that only
  copy CD's is a good idea (packet writing).

- and so on, and so on, ...

Notice that mayority of the people don't need all the patches in
Mandrake, they only need 2-3 or 4.  The problem is to have a kernel
that fits lots of people.

jos> Mandrake is not a linux distribution known for stability.

This is a bad statement.  If you explain me _why_ you told that, I can
try to fix it.  but with only that sentence, I can't, sorry :(

jos>  let's please take 
jos> stability as top priority for Mandrake 10.0. This way Mandrake will get the 
jos> good name that belongs to such a cool distribution.

Godd goal, I agree with it.  And I do my best to do it.

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: LG Drives

[Juan Quintela]

>>>>> "david" == David Walser <[EMAIL PROTECTED]> writes:

david> Juan Quintela wrote:
>>>>>>> "marc" == Marc Guise <[EMAIL PROTECTED]> writes:
>> 
marc> I read the post about Mdk 9.2 and LG on mandrakeusers.org. I have cd-rw drive, 
marc> model HL-DT-ST GCE 8400b and I have Mdk 9.2rc2 running. There are no problems 
marc> with my LG drive
>> 
>> 21mdk just updated (vdanen should be doing the official update) fixes
>> that problem.  Only LG plain CD-ROMS are affected.
>> 
>> Later, Juan.

david> A friend of mine asked to ask if the 2.6 kernel is affected by this.

not affected at all.  Only if it uses some port of packet writing
patches.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: LG Drives

[Juan Quintela]

>>>>> "juan" == Juan Quintela <[EMAIL PROTECTED]> writes:


juan> Ok, official stance (will sent to slashdot):

arghh, official as about who it is stated in the ATAPI specifications
as read from the kernel hackers.  Mandrake official stance will be
issued later.

Sorry for the confusion.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: LG Drives

[Juan Quintela]

>>>>> "bg" ==   <[EMAIL PROTECTED]> writes:

>> On Saturday 25 October 2003 07:20 pm, Juan Quintela wrote:
>>> >>>>> "marc" == Marc Guise <[EMAIL PROTECTED]> writes:
>>> 
marc> I read the post about Mdk 9.2 and LG on mandrakeusers.org. I
>>> have cd-rw drive, marc> model HL-DT-ST GCE 8400b and I have Mdk 9.2rc2
>>> running. There are no problems marc> with my LG drive
>>> 
>>> 21mdk just updated (vdanen should be doing the official update) fixes
>>> that problem.  Only LG plain CD-ROMS are affected.
>>> 
>>> Later, Juan.
>>> 
>>> PD. Yep, whoeved decided at LG that reusing for UPLOAD_FIRMAWARE
>>> command FLUSH_CACHE comand should be shoot.  Twice.
>> 
>> SO it turns out to be a firmware bug after all that.  I really hope you
>> guys  don't take the heat for this in the court of public opinion.

bg> /. posted a really badly researched post on this (with a bad title too),
bg> but it seems public opinion is that hardware shouldn't be vulnerable.

bg> It wouldn't hurt though to have an official position sent to /., I think
bg> they should reasonably update the summary to indicate that this is a
bg> hardware issue that would also affect other users, and hopefully push the
bg> availability of updates and how to use them.

Ok, official stance (will sent to slashdot):

It is not related with linux specially, it can happens in Windows
also.  It is more, you can search and find that people are also having
problems in windows.

Problem: sending a FLUSH_COMMAND to an LG drive kills it.

Expected output: Ignore the command/return one error.  FLUSH_COMMAND
support is not required.

Real Problem:  not having implemented this command is ok, but reusing
it for anything else is against the specs.  It appears that LG decided
to reuse this command for modifying the firmware.

Hope this helps, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: LG Drives

[Juan Quintela]

> "marc" == Marc Guise <[EMAIL PROTECTED]> writes:

marc> I read the post about Mdk 9.2 and LG on mandrakeusers.org. I have cd-rw drive, 
marc> model HL-DT-ST GCE 8400b and I have Mdk 9.2rc2 running. There are no problems 
marc> with my LG drive

21mdk just updated (vdanen should be doing the official update) fixes
that problem.  Only LG plain CD-ROMS are affected.

Later, Juan.

PD. Yep, whoeved decided at LG that reusing for UPLOAD_FIRMAWARE
command FLUSH_CACHE comand should be shoot.  Twice.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Huge List of Updates

[Juan Quintela]

> "ef2" == ef2  <[EMAIL PROTECTED]> writes:

Hi

ef2> I think that we need a lot more RCs, and on the contrary they should be more
ef2> frequent, a lot more frequent. Updating a cooker machine is not the same
ef2> than installing the distribution from scratch, considering the updating
ef2> scripts do not have the same effects.
ef2> For example, there should be 1 RC per 10 days or 2 weeks. Go for a RC5 or
ef2> RC6, it does not matter if one or two bugs have been squashed, but this way
ef2> you will attract more beta testers.

15 days for 6 releases = 3 months.
Being in Release Candidate mode during 3 months means that it is going
to be a bit difficult to have 6 months Release cycle :(

ef2> If you want that more people test the beta versions, you need to consider
ef2> the human psychology : the more the figure will be big, the more people will
ef2> want to try the distribution. I even suggested after 9.1 to lie about the
ef2> actual release date. Maybe this would not be really useful though.

I am thinking that if the solution is to apply "psycology", we will
have to told people that we are going to have only 1 RC and then doing
3, then people will begin to test RC1 instead of beggining testing in
RC3 :p

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Huge List of Updates

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

Hi

john> What is needed is a committed (and known) BETA, & RC
john> testers. Each one committed to testing a know set of
john> functionality (hardware & software), and regression issues.

But that things are already fixed in the Betas & RC.

Problem is that majority of the people don't test until the last RC or
Final :(  Bugs reported during cooker & Betas are normally fixed.

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: make xconfig failed

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

>> xconfig is a qt-gui. 
>> do you have libqt3-devel installed?

svetoslav> this is only the case for linux-2.6

svetoslav> and as you can see here is 2.4.22-18mdk

svetoslav> probably again alsa/ lufs/ ipsec Configure.in 
svetoslav> needs tweaking

For a change, it is not my fault (TM).

If you try to run make xconfig in a marcelo kernel (2.4.23-preX), it
also fails.

Later, Juan.


>>  ש××ש×, 21 ×××
>> ק¨ 2003, 23:09, × ××ª× ×
>> ¢× ××× Bellegarde Cédric:
>> > With last kernel-source, i can't run make xconfig ... :-/
>> >
>> > [EMAIL PROTECTED] linux]# make xconfig
>> > rm -f include/asm
>> > ( cd include ; ln -sf asm-i386 asm)
>> > if [ -f .need_mrproper ]; then \
>> > rm .need_mrproper; \
>> > make mrproper;  \
>> > make preconfig;  \
>> > fi
>> > make -C scripts kconfig.tk
>> > make[1]: Entering directory `/usr/src/linux-2.4.22-18mdk/scripts'
>> > cat header.tk >> ./kconfig.tk
>> > ./tkparse < ../arch/i386/config.in >> kconfig.tk
>> > make[1]: *** [kconfig.tk] Erreur 139
>> > make[1]: Leaving directory `/usr/src/linux-2.4.22-18mdk/scripts'
>> > make: *** [xconfig] Erreur 2
>> > [EMAIL PROTECTED] linux]#
>> 
>> -- 
>> 
>> diego, 26 Tishrey 5764
>> 
>> Please avoid sending me Word or PowerPoint attachments.
>> See http://www.fsf.org/philosophy/no-word-attachments.html
>> 
>> 
>> 



svetoslav> -- 
svetoslav> NEU FÜR ALLE - GMX MediaCenter - für Fotos, Musik, Dateien...
svetoslav> Fotoalbum, File Sharing, MMS, Multimedia-Gruß, GMX FotoService

svetoslav> Jetzt kostenlos anmelden unter http://www.gmx.net

svetoslav> +++ GMX - die erste Adresse für Mail, Message, More! +++



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: make xconfig failed

[Juan Quintela]

> "diego" == Diego Iastrubni <[EMAIL PROTECTED]> writes:

diego> xconfig is a qt-gui. 
diego> do you have libqt3-devel installed?

Hi

No, it is tk based.

Later, Juan.

diego> ביום שלישי, 21 באוקטובר 2003, 23:09, נכתב על ידי 
Bellegarde Cédric:
>> With last kernel-source, i can't run make xconfig ... :-/
>> 
>> [EMAIL PROTECTED] linux]# make xconfig
>> rm -f include/asm
>> ( cd include ; ln -sf asm-i386 asm)
>> if [ -f .need_mrproper ]; then \
>> rm .need_mrproper; \
>> make mrproper;  \
>> make preconfig;  \
>> fi
>> make -C scripts kconfig.tk
>> make[1]: Entering directory `/usr/src/linux-2.4.22-18mdk/scripts'
>> cat header.tk >> ./kconfig.tk
>> ./tkparse < ../arch/i386/config.in >> kconfig.tk
>> make[1]: *** [kconfig.tk] Erreur 139
>> make[1]: Leaving directory `/usr/src/linux-2.4.22-18mdk/scripts'
>> make: *** [xconfig] Erreur 2
>> [EMAIL PROTECTED] linux]#

diego> -- 

diego> diego, 26 Tishrey 5764

diego> Please avoid sending me Word or PowerPoint attachments.
diego> See http://www.fsf.org/philosophy/no-word-attachments.html




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: make xconfig failed

[Juan Quintela]

> "bellegarde" == Bellegarde Cédric <[EMAIL PROTECTED]> writes:

Hi
looking at this problem.

xconfig code just sucks big time :(

For some reason a pointer becomes -1, haven't find still _why_.

Have I already told you that xconfig code sucks, not a single malloc()
return value is tested :(

/me hopes to find something today

Later, Juan.

bellegarde> With last kernel-source, i can't run make xconfig ... :-/
bellegarde> [EMAIL PROTECTED] linux]# make xconfig
bellegarde> rm -f include/asm
bellegarde> ( cd include ; ln -sf asm-i386 asm)
bellegarde> if [ -f .need_mrproper ]; then \
bellegarde> rm .need_mrproper; \
bellegarde> make mrproper;  \
bellegarde> make preconfig;  \
bellegarde> fi  
bellegarde> make -C scripts kconfig.tk
bellegarde> make[1]: Entering directory `/usr/src/linux-2.4.22-18mdk/scripts'
bellegarde> cat header.tk >> ./kconfig.tk
bellegarde> ./tkparse < ../arch/i386/config.in >> kconfig.tk
bellegarde> make[1]: *** [kconfig.tk] Erreur 139
bellegarde> make[1]: Leaving directory `/usr/src/linux-2.4.22-18mdk/scripts'
bellegarde> make: *** [xconfig] Erreur 2
bellegarde> [EMAIL PROTECTED] linux]# 




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: highmem bug in BadRAM kernel patch

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

Hi
already in 18mdk.

Later, Juan.


>> some time ago a bug has been found in the badram patch that marks highmem 
>> pages either completely bad or completely good.
>> 
>> see http://www.ussg.iu.edu/hypermail/linux/kernel/0307.0/0256.html for 
>> the complete story.
>> 

thomas> Ouch :-(

>> A patch against kernel-2.4.22.10mdk-1-1mdk can be downloaded from here:
>> 
>> http://www.bestsolution.at/documents/BadRAM-2.4.22.10mdk-1-1mdk.patch.bz2
>> 
>> The original patch provided by me also omitted the badram documentation,
>> which is included in this patch now as well.
>> 
thomas> Nice ...
thomas> will add to my next build

thomas> Regards

thomas> Thomas



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: No kernels on uninett ?

[Juan Quintela]

> "frank" == Frank Griffin <[EMAIL PROTECTED]> writes:

frank> I resync'd cooker with ftp.uninett.no about an hour ago, and found
frank> that all of my .15 kernels were deleted with no replacements.  Sure
frank> enough, all of the cooker kernel files (except for the docs) are gone
frank> from the mirror.

frank> I've continued to check over the past hour, so this isn't a case of an
frank> update in-flight.

18mdk kernels have been released in Monday morning.  I don't know how
fast/slow normally takes the mirrors to propagate.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.22.16mdk-1-1mdk

[Juan Quintela]

>>>>> "buchan" == Buchan Milne <[EMAIL PROTECTED]> writes:

buchan> Juan Quintela wrote:
>> Juan Quintela <[EMAIL PROTECTED]> 2.4.22-16mdk
>> 
>> - new adi id for ac97_codec.
>> - alsa-usb-audio fix (tmb).
>> - new qcamvc 1.0.6 driver, please told me if it works.
>> - ich3 minor ide fixes.
>> - nforce2 people have UDMA133 support (tmb).
>> - powernow k7 (from tmb), please test and report.
>> - redo acpi update to 2.4.23-pre6.
>> - fix BadRAM and HighMem (why nobody complained yet is a mistery).
>> - fix usb-audio.

buchan> Good to see the fixes going in, but it would be nice to see cloop-1.02
buchan> ... since at present mklivecd (in contrib) is really only useful with
buchan> the tmb kernel. It would be nice to have it working on an official
buchan> kernel (or did it just escape the changelog?).

It is not there :(

Will be in 18mdk (17mdk already building).

Can someone told me a "course for stupids" about mklivecd?

I mean something like:

urpmi mklivecd
mklivcd foo bar

launch foo .

If it can be tested automatically, I will add it to my automatic
regression tests :)

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: nvidia driver messes up console mode (framebuffer?)

[Juan Quintela]

> "jay" == Jay DeKing <[EMAIL PROTECTED]> writes:

Hi

jay> On Wednesday 08 October 2003 5:51 am, John Allen honored me with this 
jay> communique:
>> On Tuesday 07 October 2003 21:47, Luca Olivetti wrote:
>> > John Allen escribió:
>> > > Don't use NVIDIA's 4496. Anything later than 4191 is a disaster; from
>> > > console more screwups to reboots, and X hard locks.
>> >
>> > Funny, I could say the same for anything *earlier* than 4363 (adding
>> > filesystem corruption to the mix).
>> > Maybe it's just nvidia releasing crap in *every* version.
>> 
>> Ah well, YMMV as they say.
>> 
>> I have found that with my geForce4 MX440's only 4191 is stable.
>> 
>> > Bye

jay> Still running 4191 myself: GeForce MX 420. Can't get anything later to compile 
jay> properly, and 4191 seems to work just fine.

jay> I hate those darn ".run" files, anyway.

Grrr,  NVidia cards are just making my life miserable.  I have almost
the same hardware that one of the Bug reporters and things work well
for me.

I need to try to found a pattern somewher.  Until now it appears that:

- drivers 4363 works for a lot of people.
- drivers 4496 fails for several people (they work for me).

Can people please mail me the output of lspcidrake -v and telling me
what versions work/don't work for you?

I have found that machines fail with PIII, PIV and athlons, both with
NVidia IGP and normal cards.

Only pattern found until now are that the following cards fail:

- GForce MX
- Gforce2 MX
- IGP (Gforce4 MX)
- standalone GForce4 MX

At least the:
- GForce3 Ti500 work (guess what is the card that I have)


Current theory is that:

New driver with cards older than GForce3 fail.  GForce4 MX if I
remember correctly is just a GForce2 core "on steroids".


Later, Juan "learning too much about NVidia graphics cards".

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: perms on /dev/rtc device

[Juan Quintela]

>>>>> "guillaume" == Guillaume Rousse <[EMAIL PROTECTED]> writes:

guillaume> Ainsi parlait Juan Quintela :
>> >>>>> "olivier" == Olivier Blin <[EMAIL PROTECTED]> writes:
>> >>
>> >> # RTC resolution
>> >> dev.rtc.max-user-freq = 1024
>> >>
>> >> Could this setting be added in default sysctl.conf ?
>> 
olivier> Thanks, but shouldn't this be the default in default security
>> level ? olivier> RTC works fine, but sysctl.conf need to be tweaked.
olivier> IMHO, the user shouldn't have to do that.
>> 
>> Problem is that in a multiuser system, if you allow the value 1024,
>> you can create a DOS if several users use that.
guillaume> I guess most multimedia applications are only usable by local user, not a 
guillaume> remote one, which means only one at a time. This should reduce DOS risks, 
no?

No.  any user can do a very small script/c program an use the whole
number of timers.  Machine is on its knees :(

guillaume> What about adding this setting only through mplayer, tvtime
guillaume> and other packages requiring it %post/%postun facilities ?

Really it is too agresive to set it _unconditionally_.


>> Default value of 64 should be enough except for single-user machines
>> running an _almost_ real time application.  And yes, for today
>> machines, mplayer is still real-time like application.
guillaume> Not sure to understand what you mean there.

That the value only make sense for single user machines, or for
machines when you trust all the users will not do something
dumb/trying to crash your server.

Only way to handle it automagically is having a option in the
installer/MCC telling something like:

- this is a mono-user system/I trust all the users

Only other easy thing that I can think is teaching msec to set it at
the most "unsecure" level.  And I am not sure that people will be
using that level at all :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: perms on /dev/rtc device

[Juan Quintela]

> "olivier" == Olivier Blin <[EMAIL PROTECTED]> writes:

>> # RTC resolution
>> dev.rtc.max-user-freq = 1024
>> 
>> Could this setting be added in default sysctl.conf ?

olivier> Thanks, but shouldn't this be the default in default security level ?
olivier> RTC works fine, but sysctl.conf need to be tweaked.
olivier> IMHO, the user shouldn't have to do that.

Problem is that in a multiuser system, if you allow the value 1024,
you can create a DOS if several users use that.

Default value of 64 should be enough except for single-user machines
running an _almost_ real time application.  And yes, for today
machines, mplayer is still real-time like application.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.22.5mdk-1-1mdk

[Juan Quintela]

>>>>> "danny" ==   <[EMAIL PROTECTED]> writes:

>> Juan Quintela wrote:
>> -=-=-=-
>> Name: kernel-2.4.22.5mdk   Relocations: (not relocateable)
>> Version : 1 Vendor: MandrakeSoft
>> Release : 1mdk  Build Date: Fri Sep  5
>> 15:10:17 2003
>> Install Date: (not installed)   Build Host:
>> no.mandrakesoft.com
>> Group   : System/Kernel and hardwareSource RPM: (none)
>> Size: 38819571 License: GPL
>> Signature   : (none)
>> Packager: Mandrake Linux Team <http://www.mandrakeexpert.com>
>> URL : http://www.kernel.org/
>> Summary : The Linux kernel (the core of the Linux operating system).
>> 
>> -=-=-=-
>> Juan Quintela <[EMAIL PROTECTED]> 2.4.22-5mdk
>> 
>> - make xconfig works again (lufs is fixed).
>> - fix another mising  for firmware_class (gb).
>> - reenable i686-up-4GB and p3-smp-64GB, modversions should work now.
>> - mydsdt removed (now it is included in the initrd).

No full pre2, only selected bits.

danny> Can we please have the bugfix for supermount (v 1.2.9) ? it fixes the 
danny> init.h on non-i386, and It fixes the "stale NFS 
danny> handle" error when doing ls in /mnt/cdrom.

But we can have the ethertool fixes and supermonut v1.2.9.  Althought
the init.h thing has already been fixed.


danny> btw, Juan: why was mini-lowlat removed? What exactly went wrong? I 
danny> currently have also a problem in getting full lowlat working with 2.4.22, 
danny> just wondering if you also got schedule called during an interrupt? Any 
danny> idea how to fix?

Yep, I also get it, and have _no_ idea why it happens.  It is in a
section of code were lowlatency makes no changes.  My guess is that it
is related with the swsuspend code, but were unable to arrive to one
conclusion :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: iptables vs network scripts

[Juan Quintela]

> "jam" == J A Magallon <[EMAIL PROTECTED]> writes:

jam> Hi...
jam> I have noticed that iptables start before than network:

jam> werewolf:/etc/rc.d/init.d# head -n5 iptables
jam> #!/bin/sh
jam> #
jam> # Startup script to implement /etc/sysconfig/iptables pre-defined rules.
jam> #
jam> # chkconfig: 2345 03 92
jam> werewolf:/etc/rc.d/init.d# head -n5 network
jam> #! /bin/bash
jam> #
jam> # network   Bring up/down networking
jam> #
jam> # chkconfig: 2345 10 90

jam> Shoud not start after ?

Hi

No.  
Idea at least is that 1st you start the firewall, and then you
start the network.  This way you are not unprotected for a
single moment.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Is there somewhere I can get the all the old Mandrake kernels??

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

I have all the linux-2.4.*-*q* tars on my hard-disk.  If you want, I
can make it available (but they are _big_).  I don't have it as
rpm/src.rpm, but building a kernel from this is basically trivial,
just replace numbers in the actual kernel-2.4.spec and recompile.

quintela$ du -s ~/work/kernel/history/
3.4G/home/mitica/quintela/work/kernel/history

This are the whole things untared (very useful for searching changes).

Later, Juan.

I can make it online, but I will be more happier if I substitute files
that are identical by symlinks to the previous version.  Notice that
there are lots of things that are basically identical, that will mean
that it will use much less space.  Any "script guru" that can make a
script that given 2 directories, just md5sum files, and if they are
identical, just removes file and makes a symlink? 

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: 2.4.22-3mdk had knackered autoconf.h

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

john> It is full of -up-, and -smp- rather then _up_ _smp_

Hi

That is the reason that in 4mdk i686-up-4GB and p3-smp-64GB are
disabled.  Sorry for the problems.

Later, Juan "digging in the two ~300 line sed scripts trying to fix
the mess.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.22.4mdk-1-1mdk

[Juan Quintela]

>>>>> "facorat" == FACORAT Fabrice <[EMAIL PROTECTED]> writes:

facorat> Le lun 01/09/2003 à 09:21, Juan Quintela a écrit :
>> -=-=-=-
>> Name: kernel-2.4.22.4mdk   Relocations: (not relocateable)
>> Version : 1 Vendor: MandrakeSoft
>> Release : 1mdk  Build Date: Mon Sep  1 10:56:30 2003

facorat> strange pb.
facorat> + can't install it as kernel-2.4.22.0.6mdk-1-1mdk requires kernel-utils
facorat> version greater than 1.1, but nothing provides kernel-utils :

kernel-utils has died, replaced by bootloader-utils, as pixel already
explained kernel-utils is _too_ confusing for lot of reasons.

I am still thinking if it is a good idea to put a Provides:
kernel-utils in bootloader-utils, as there were only a couple of
cooker kernels that require it (i.e. it is probably more confusing
that just forcing/removing that two old kernels).

I am open to suggestions, anyways.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-2.4.22-0.7, compiled with gcc 3.3.1 causes hard locks onmy machine

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

Hi

john> This probably explains what the problem is then; I'm getting UDMA100 with the 
john> 2.4.22-0.8, and this is probably the source of the problem.

Please, check that you have a real 80 pins cable. It appears that for
some reason, the cable is misdetected.

john> I've also put the 2.4.22 kernel on my other machine (NF7-S V1.2, which is 
john> normally very stable), and X crashed after 3 hours, with console video 
john> knackered.

not here, could you try a serial console to see the hang?

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Kernel 2.4.22.1mdk fails to install

[Juan Quintela]

> "serge" == Serge Pluess <[EMAIL PROTECTED]> writes:

serge> Hi
serge> when installing the kernel-2.4.22.1mdk-1-1mdk.i586.rpm both with urpmi or rpm 
serge> -ivh I get the following error message :

serge> ln: invalid option -- o
serge> Try `ln --help' for more information

This is very weird, because:
a- it works here (tm)

quintela$ sudo rpm -ivh /RPMS/kernel-smp-2.4.22.1mdk-1-1mdk.i586.rpm 
warning: /RPMS/kernel-smp-2.4.22.1mdk-1-1mdk.i586.rpm: V3 DSA signature: NOKEY, key ID 
70771ff3
Preparing...### [100%]
   1:kernel-smp-2.4.22.1mdk ### [100%]
quintela$ rpm -qa bootloader-utils
bootloader-utils-1.3-1mdk


b- I can't find a ln with -o argument in the whole
bootloader-utils/kernel spec file.

Could you paste the full log, just if I can make any sense of it :(

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-2.4.22-0.7, compiled with gcc 3.3.1 causes hard locks onmy machine

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

Hi

>> That is very, very weird.
>> 
>> If I remembered correctly You told me that for you 2.4.21 is faster
>> than 2.4.22.  (~50MB/s vs ~20MB or something like that).
>> 

john> Nope, its the other way around; 50 for 2.4.22, and 27 for 2.4.21

Oh, that makes much more sense

>> 
>> You have in _both_ dmesg messages acpi disabled (that means that acpi
>> can't be related with that).
>> 
>> What is more strange is that in 2.4.21 your disk is recognized as UDMA33
>> one, instead of UDMA100.
>> 
>> Could you check that your cable is UDMA100 really?
>> 
>> -hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63,
>> UDMA(33) +hda: 156301488 sectors (80026 MB) w/8192KiB Cache,
>> CHS=9729/255/63, UDMA(100)
>> 
>> This are the relevant lines.  If I remembered rigth, you can't get
>> 50MB/s with UDMA33.
>> 

john> This probably explains what the problem is then; I'm getting UDMA100 with the 
john> 2.4.22-0.8, and this is probably the source of the problem.

>> 
>> hdparm -i output with both kernels should be more interesting.
>> 
>> And could you please send me the dmesg output with apci=on (i.e no
>> pci=noacpi neither acpi=off).
>> 

john> I trying to do a clean re-install, but current cooker (locally generated ISO) 
john> is not installable.

john> I've also put the 2.4.22 kernel on my other machine (NF7-S V1.2, which is 
john> normally very stable), and X crashed after 3 hours, with console video 
john> knackered.

john> Will keep everyone posted.

Ouch :(

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel install - no build link

[Juan Quintela]

> "buchan" == Buchan Milne <[EMAIL PROTECTED]> writes:

CC'd flepied, that is supposed to be the rpm master.

buchan> Paul Misner wrote:
>> The way to manually correct this has been discussed on the cooker
buchan> list, but it
>> is surprising to find this problem still present.  Is it associated
buchan> with the
>> conflicts between kernel-utils and bootloader-utils?

My understanding is that when one package replaces other, this is
enough:

Obsoletes: kernel-utils
Provides: kernel-utils

I think that the problem was the _manual_ installation of
installkernel after bootloader-utils.

Fred, do I need to add a Conflicts tag, or removing kernel-utils from
the repository should be enough?

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Problem with conditional build

[Juan Quintela]

> "buchan" == Buchan Milne <[EMAIL PROTECTED]> writes:

buchan> Luca Berra wrote:
>> On Mon, Aug 25, 2003 at 11:38:42PM +0200, Guillaume Rousse wrote:
>> 
>>> Conditional build in package is often defined using
>>> %define build_foo 0
>>> %{?_with_foo: %{expand: %define build_foo 1}}
>>> this way, to allow condition foo, you can either edit the spec file
>>> and change its value to 1, or use --with foo on command line when
>>> building the package.
>>> 
>>> However, it seems rpm 4.2 has a bug processing ?_with directive, or at
>>> least changed behaviour since latest version. It is now only local to
>>> current rpm section.
>> 
>> 
>> it should be written:
>> %define build_foo 0
>> %{?_with_foo: %{expand: %%global build_foo 1}}
>> 

buchan> Dump the %expand, it's not necessary:
buchan> %{?_with_foo: %global build_foo 1}

Didn't knew :(

kernel uses old form and it is working well here (changing to new form
anyways).

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-2.4.22-0.7, compiled with gcc 3.3.1 causes hard locks onmy machine

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

Hi

  Just send reply to list also, if somebody has similar problem.

john> Please find attached, dmesg, and hdparm outputs from 2.4.21-0.18mdk, and 
john> 2.4.22-0.8mdk

john> Tried 2.4.22 with all possible combos of acpi=off, noapic, pci=noacpi to no 
john> avail.

john> I will tried installing the WD drive in an NF7-V1.2 board later, and a Maxtor 
john> in the 2.0 board, to see if it is hard disk related, or mobo related.


That is very, very weird.

If I remembered correctly You told me that for you 2.4.21 is faster
than 2.4.22.  (~50MB/s vs ~20MB or something like that).


You have in _both_ dmesg messages acpi disabled (that means that acpi
can't be related with that).

What is more strange is that in 2.4.21 your disk is recognized as UDMA33
one, instead of UDMA100.

Could you check that your cable is UDMA100 really?

-hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63, UDMA(33)
+hda: 156301488 sectors (80026 MB) w/8192KiB Cache, CHS=9729/255/63, UDMA(100)

This are the relevant lines.  If I remembered rigth, you can't get
50MB/s with UDMA33.


hdparm -i output with both kernels should be more interesting.

And could you please send me the dmesg output with apci=on (i.e no
pci=noacpi neither acpi=off).

Thanks, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: latest lilo take ages to run

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

Hi
just to share news about this problem, I report my findings so far:

thomas> From: "Guillaume Rousse" <[EMAIL PROTECTED]>
>> [EMAIL PROTECTED] linux]# time lilo
>> Added linux.home *
>> Added linux.dhcp
>> Added linux.lis
>> Added linux.nodevfs
>> Added linux.old
>> Added windows
>> 0.05user 2.63system 2:33.71elapsed 1%CPU (0avgtext+0avgdata 0maxresident)k
>> 0inputs+0outputs (147major+35minor)pagefaults 0swaps
>> 
>> two minutes and a half !!!
>> 
>> [EMAIL PROTECTED] linux]# rpm -q lilo
>> lilo-22.5.7.2-2mdk
>> 

thomas> do a lilo -v5 and look what's keeping it busy...

thomas> Are you using reiserfs by any chance...?

Just to make things more strange, I have the problem here in some
machines, and not in other machines.  As I re-install machines a lot,
and I use different filesystems each time, I think that it is not
filesystem related.

Last pattern that I found is that it appears that the never the
machine, the slower it appears to be with lilo.

root$ time lilo
Added linux
Added linux-ent *
Added failsafe
Added floppy
Added 2422-07ent
0.03user 1.44system 0:12.30elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (145major+35minor)pagefaults 0swaps

with reiser as root filesystem.

I have _lots_ of messages like this.  It appears that tail's are involved.

fd 5: REISERFS_IOC_UNPACK
fd 5: offset 512 -> dev 0xe0, LBA 160952
fd 5: REISERFS_IOC_UNPACK
fd 5: offset 1024 -> dev 0xe0, LBA 160953
fd 5: REISERFS_IOC_UNPACK
fd 5: offset 1536 -> dev 0xe0, LBA 160954
fd 5: REISERFS_IOC_UNPACK
fd 5: offset 0 -> dev 0xe0, LBA 160951



Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-2.4.22-0.7, compiled with gcc 3.3.1 causes hard locks onmy machine

[Juan Quintela]

> "john" == John Allen <[EMAIL PROTECTED]> writes:

john> I have an Abit NF7-v2.0, and a Western Digital Caviar 80GB. This locks hard 
john> with the aformentioned kernel. (current in cooker). It works fine with 
john> 2.4.21-0.16 compiled with gcc 3.2.2.

john> The system will work for a period, but then just locks, usually with the hard 
john> disk light on solid.

john> hdparm -t says I'm getting 54MB per sec with 2.4.22, and 27.33 with 2.4.21, 
john> hope this provides a clue. I'm personally thinking its a gcc problem.

please, try booting with (in order) to see if the crash stop:

i- noapic
ii- pci=noacpi
iii- acpi=off

sending output of dmesg of 2.4.21 & 2.4.22 could also try to give a
clue.

Thanks, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Kernel panic on 9.2 beta 2 shutdown...

[Juan Quintela]

> "mark" == Mark Watts <[EMAIL PROTECTED]> writes:

mark> Just caught this on my laptop. Bootsplash let me hit F2 and this was there 
mark> (typed by hand):

mark> NB: Filesystems are all ext3..




mark> Splash status on console 0 changed to on
mark> Got silent jpeg.
mark> Unable to handle kernel paging request at virtual address 7ad0103b
mark> printing eip:
mark> d89f33c3
mark> *pde = 
mark> Oops: 
mark> radeon i810_audio ac97_codec soundcore nfsd ds yenta_socket pcmcia_core 
mark> af_packet sr_mod floppy 3c95x supermount ide-cd cdrom ide-scsi scsi_mod 
mark> udb-uhci usbcore rtc ext3 jbd
mark> CPU:0
mark> EIP:0010:[]Not tainted
mark> EFLAGS: 00010286
mark> EIP is at E journal_blocks_per_page_R776ce4b4+0xcd03/0xb440 [jbd]
mark> eax: d3b25f54   ebx: d3d5b220   ecx: d3d5b220   edx: d74b13c0
mark> esi: d5919220   edi: d37ed840   ebp: d74b13c0   esp: d3d25f50
mark> ds: 0018  es: 0018  ss: 0018
mark> Process rm (pid: 4772, stackpage=d3d25000)
mark> Stack: fffe d7416168 fff0 d5919220 d591929c d3d5b220 c014f1f1 d5919220
mark> d3d5b220 d3d5b220 d07be000 d3d5b220 d3d25f90 c014f2ee d5919220 d3d5b220
mark> d7d94720 c142f420 d07be011 0009 fbc2cce6 0010  0004
mark> Call Trace:
mark> [] vfs_unlink+0x131/0x1a0 [kernel]
mark> [] sys_unlink+0x8e/0x100 [kernel]
mark> [] system_call+0x33/0x40 [kernel]

mark> Code: f7 74 7c 6b ff ff ff 7a 3f f0 7b b1 fe 00 00 f6 80 80 00 00
mark> /etc/rc0.d/K00linuxconf: line 31: 4772 Segmentation faultrm -f 
mark> /var/lock/subsys/linuxconf

Arghh, to make things more complicated, stack trace is just broken,
great :(

/me will try here. Just strange, as I use ext3 also here.

Will insntall kde and test with it (/me is just a real men and use
fvwm2 :)

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] lilo-22.5.7.2-1mdk

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

thomas> From: "Pixel" <[EMAIL PROTECTED]>
>> "Thomas Backlund" <[EMAIL PROTECTED]> writes:
>> 
>> > doing a lilo -v5 shows:
>> > 
>> > --- cut ---
>> > Calling map_insert_data
>> > fd 5: REISERFS_IOC_UNPACK
>> > fd 5: offset 2560 -> dev 0xe0, LBA 8011921
>> > fd 5: REISERFS_IOC_UNPACK
>> > fd 5: offset 3072 -> dev 0xe0, LBA 8011922
>> > --- cut ---
>> > 
>> > the same goes on and on and on
>> > seems it's about to scan every block on reiserfs...
>> 
>> booh. lilo-22.5.X seems really not stable... I'm wondering if the best
>> solution would not be to switch to lilo-22.4.1 ...
>> 

Arghhh.

Guilty should be datalogin patches of reiserfs.  Will take a look
there.

Later, Juan.

thomas> Actually lilo is not to blame for this...

thomas> It's a kernel reiserfs bug :-(

thomas> I verified this by installing lilo from MDK 9.1 ... same problem...
thomas> Then I tested my 2.4.22-0.5.2tmb_mdk ... same problem...

thomas> Going back to 2.4.21-6.5tmbsecure ...  everyhing works...
thomas> So we have picked up a reiserfs bug between 2.4.21-6mdk 
thomas> and 2.4.22-0.5mdk... :-(

thomas> Seems I have my weekend planned now... this is _bad_

thomas> Juan,
thomas> are you able to replicate this?

thomas> [EMAIL PROTECTED] thomas]$ mount
thomas> /dev/sda7 on / type reiserfs (rw,notail)
thomas> none on /proc type proc (rw)
thomas> none on /proc/bus/usb type usbfs (rw)
thomas> none on /dev/pts type devpts (rw,mode=0620)
thomas> /dev/sdb7 on /var type reiserfs (rw,notail)
thomas> /dev/md0 on /home type reiserfs (rw,notail)
thomas> /dev/md1 on /var/spool/squid type reiserfs (rw,notail)
thomas> /dev/hda1 on /Data/Disk1 type xfs (rw)
thomas> /dev/hdc1 on /Data/Disk2 type xfs (rw)


thomas> BTW, is there anyone having an 2.4.22-0.1mdksecure rpm?
thomas> I want to check if this bug came when we switched to pre10,
thomas> or when we switched to rc2 ...


thomas> Thomas


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: 2.4.22.0.5mdk - still no i2c-nforce2

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

thomas> Viestissä Lauantai 16 Elokuu 2003 03:07, Adam Williamson kirjoitti:
>> come on kernel guys, *please* get this in there...I reported it last
>> week, despite the i2c fixes in 0.5mdk, it's still not got in :(. No
>> reason to ship 9.2 with nforce2 users unable to use lm_sensors!

thomas> The reason it got left out is because the mkpatch scripts in lmsensors/i2c 
thomas> packages are not updated according to their 2.8.0 contents...

thomas> I have spent a long time on fixing the patches so that they will be 
thomas> integrated... and they will be in my next kernel...

thomas> Since Juan accepted many of my and svetljo's patches into 5mdk
thomas> I didn't finish up my 3.1tmb... instead I spent my time
thomas> resyncing all my patches against 0.5mdk, and dropped those
thomas> that got integrated...

thomas> I have now a patchset with ~30 patches that I'm compiling right now

thomas> If nothing breaks, my 5.1tmb rpms will be ready when I wake up...
thomas> (haven't slept for almost 24 hours ..., but now I'm going to bed)


There is 7mdk.

 ls /lib/modules/2.4.22-0.7mdksmp/kernel/drivers/i2c/i2c-nforce2.o.gz 

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: depmod: *** Unresolved symbols in /lib/modules

[Juan Quintela]

> "guran" == guran  <[EMAIL PROTECTED]> writes:

guran> Hi
guran> I have had the following in the last two installations in boot.log:
guran> Aug 10 00:16:34 localhost depmod: depmod:
guran> Aug 10 00:16:34 localhost depmod: *** Unresolved symbols in 
guran> /lib/modules/2.4.22-0.1mdk/kernel/drivers/atm/he.o.gz
guran> Aug 10 00:16:34 localhost rc.sysinit: Finding module dependencies:  succeeded

Should be fixed in 2.4.22-0.7mdk.  
/me just hates people that make patches and don't use modversions :(

Thanks for the report, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Patching kernel

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

Hi

Just a new comment about patches:

Reason why I used names like:

AB01-2_blah.patch

was to make it easy to distinguih with a single

ls /patches > d1
ls /patches > d2

diff d1 d2

showed me what patches changed between one and the other, the only
thing that had to happen was that if a patch change, its name *must*
also change.

As other people (myself included) forgotted to update names when
rediffing, I do now a:

cd /patches; md5sum * > d1
cd /patches; md5sum * > d2

diff d1 d2

Then it is not necessary to have the ugly

AB01-2_blah.patch  names.

AB01_blah.patch should be enough.

svetoslav> i don't have one (can you send me yours :) )

attached :)

Now that we are on that, will show full set of alias & shell functions
for your .bashrc

way that I release kernel:

tar xvfj linux-2.4.21.tar.bz2

# kcp hardlinks the trees, making operation very fast and very space 
# efficient, you need an editor than understand hardlinks (i.e. when
# it oppens a file with numer of links > 1, it copies the file when
# you modify it, don't update inplace).  emacs knows how to do it, vim
# by default no.

kcp linux-2.4.21 w1
cd w1
/2.4.21-q1/scripts/apply_patches

some patch fail, namely AB01_something.patch

fix rejects

cd ..
d1 w1/ .ab01
# only diff between d1 & d2 is that d1 remove the /tmp/d file if it
# already exists
d2 w1/ .ab01

edit AB01_something.patch
see if the changes are good, and change the differences of the files.

continue apply_patches with next patch.

Here are the aliases.

# write protect a directory, very useful with kcp below

kprotect ()
{
local directory=$1
find $directory -type f | xargs chmod a-w
}

# Made the diff of of file.orig and file
temp_file=/tmp/d

# Extra Bonus: does somebody how to convince diff to type the diff
# line when diffing a single file?

d2 () {  
local filename=$1
local version=$2
echo "diff -uNp ${filename}${version}.orig ${filename}" >> $temp_file
/usr/bin/diff -uNp ${filename}${version}.orig ${filename} >> $temp_file
}

d1 () {  
local filename=$1
local version=$2
# truncate dest file
cp -f /dev/null $temp_file
d2 $filename $version
}


# The k* build kernel functions

alias knone='~/bin/r --without up --without smp --without enterprise --without BOOT 
--without secure --without source --without doc SPECS/kernel-2.4.spec'

alias kup='knone --with up'
alias kboot='knone --with BOOT'
alias ksmp='knone --with smp'
alias kent='knone --with enterprise'
alias ksecure='knone --with secure'

# now you can compile only an SMP kernel with with debug with
# ksmp -bb --with debug
# ~/bin/r is simply a shell script with that allows me to compile
# things in any dir.

#!/bin/sh

export LC_ALL=C
exec rpm --define "_topdir $PWD" --define "_tmppath $PWD/tmp" $*
 
# end r

alias rdiff='/usr/bin/diff -urNp --exclude=CVS --exclude="*~" --exclude=".#*" 
--exclude=TAGS'
alias diff='/usr/bin/diff -up'
alias kdiff='/usr/bin/diff -urNp --exclude-from=$HOME/config/misc/dontdiff'
alias kcp='cp -dpilR'
alias minstall="make INSTALL_MOD_PATH=/tmp/kk modules_install"

# kdiff is very good to diff kernel-trees, it is very fast if you are
# using hard-linked trees (i.e. created with kcp), and the dontdiff
# file just told files that you are not interesested in.
# 
# ExtraBonus:  How to put a directory with a dir/file thing.
 


svetoslav> hm, i think it shouldn't be a problem, but ..
svetoslav> i can not give you a good explanation so ..
svetoslav> you might drop it if you think it might break smth.

svetoslav> (
svetoslav> i couldn't get it running with my CD/DVD writers,
svetoslav> and the patch was not really tested/ it was intended just for review by 
Thomas
svetoslav> ) 
 
I did a couple of small changes in it.  Will try harder later.

Later, Juan.



dontdiff
Description: don't diff file


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: /sbin/installkernel broken

[Juan Quintela]

> "j" == J A Magallon <[EMAIL PROTECTED]> writes:

j> Hi all...
j> I have tried to build latest -rc2, and installkernel can't find the
j> image to install:

Hi
fixed in bootloader-utils 0.13 just released.

Later, Juan.

j> + exec /sbin/installkernel 2.4.22-rc2-jam1m bzImage
j> /usr/src/linux-2.4.22-rc2-jam1m/System.map /boot
j> cat: bzImage: No such file or directory

j> This makes things work again:

j> --- installkernel.orig   2003-08-17 02:03:43.0 +0200
j> +++ installkernel2003-08-17 02:24:11.0 +0200
j> @@ -190,8 +190,6 @@
 
j> [[ -n $4 ]] && boot=$4 || boot=/boot
 
j> -cd $boot
j> -
j> [[ $AUTOREMOVE = "no" ]] && REMOVE=""
j> [[ $NOLINK = "yes" ]] && NOLINK=-n
 
j> Problem is that it leaves the script sitting at /boot and installkernel
j> is called with relative paths from arch/i386/boot.

j> Some change for specific mandrake things ? If it makes building standard
j> kernels fail...

j> TIA

j> -- 
j> J.A. Magallon <[EMAIL PROTECTED]>  \ Software is like sex:
j> werewolf.able.es \   It's better when it's free
j> Mandrake Linux release 9.2 (Cooker) for i586
j> Linux 2.4.22-rc1-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk))


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-tmb-2.4.22-0.5.2tmb_mdk(dvb-core needed by net devices?)

[Juan Quintela]

> "steffen" == Steffen Barszus <[EMAIL PROTECTED]> writes:

Hi
answering to the last mail of the thread just if somebody
didn't saw my first answer.

I found this problem, and it should be fixed in 2.4.22.0.7mdk
just released.

Thanks, Juan.

steffen> Am Mittwoch, 20. August 2003 02:24 schrieb Svetoslav Slavtchev:
>> Quoting Steffen Barszus <[EMAIL PROTECTED]>:
>> > Am Dienstag, 19. August 2003 23:39 schrieb Svetoslav Slavtchev:
>> > > Quoting Steffen Barszus <[EMAIL PROTECTED]>:
>> > > > Am Dienstag, 19. August 2003 22:55 schrieb Svetoslav Slavtchev:
>> > > > > Quoting Steffen Barszus <[EMAIL PROTECTED]>:

>> > > can you may be post your modules.conf & devfsd.conf changes ?
>> >
>> > I have done this allready. Maybe the mail didn't came trough and it
>> > was not in this thread. So here they come:
>> >
>> >
>> > REGISTER ^dvb/adapter[0-9]+/[^/]+$   PERMISSIONS root.video 0660
>> > REGISTER ^ost/video[0-9]+$   PERMISSIONS root.video 0660
>> > REGISTER ^v4l/[^/]+[0-9]+$   PERMISSIONS root.video 0660
>> >
>> > Thats what I have, but
>> >
>> > REGISTER ^dvb/adapter[0-9]+/[^/]+$   PERMISSIONS root.video 0660
>> > REGISTER ^v4l/[^/]+[0-9]+$   PERMISSIONS root.video 0660
>> >
>> > would be enough I think.
>> 
>> only for managing permissions? no symlinks? modload ?

steffen> dvb/adapter doesn't need links for compatibility, /dev/video is 
steffen> elsewhere in the devfs config. If parts of the modules.conf can be put 
steffen> in devfs config it would be fine too, but I don't understand the devfs 
steffen> magic really ;)

>> > And my modules.con entries:
>> >
>> > probeall /dev/dvb dvb-ttpci
>> > alias /dev/dvb/* /dev/dvb
>> > below dvb-ttpci alps_bsrv2 alps_tdmb7 alps_tdlb7
>> > add below dvb-ttpci grundig_29504-401 grundig_29504-491
>> > add below dvb-ttpci stv0299 ves1820
>> 
>> do you really need all frontends?
>> am i missing smth or a single frontend should be sufficient for a
>> single dvb card ? ( or more, you don't have diffrent kinds right?)

steffen> Well. This works for all cards with Vendor Id 1131 and Prod Id 7146. Why 
steffen> make it more difficult and trying to distinguish on Subvendor and sub 
steffen> product Id which frontend is used ? 

>> > I can take that out and see if i can reproduce it here if one or
>> > both, or parts of it are taken out. Will do so tomorrow morning and
>> > post results
>> 
>> i'll check it here with your config addjustments
>> let see what will hapen :)

steffen> Ok :)

steffen> Steffen


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-tmb-2.4.22-0.5.2tmb_mdk(dvb-core needed by net devices?)

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

svetoslav> Quoting Thomas Backlund <[EMAIL PROTECTED]>:
>> %changelog
>> * Mon Aug 18 2003 Thomas Backlund <[EMAIL PROTECTED]> 2.4.22-0.5.2tmb_mdk
>> - drop psaux synaptics patch until I have time to fix it
>> - fix mod_dvb patch to use new build framework
>> 
>> * Sat Aug 16 2003 Thomas Backlund <[EMAIL PROTECTED]> 2.4.22-0.5.1tmb_mdk
>> 
 
svetoslav> Hi Thomas ,

svetoslav> not a real complain (because i added my test dev-mapper patches),
svetoslav> but it seems a bit strange:
svetoslav> 
svetoslav> i2c-proc8052   0  [w83781d eeprom]
svetoslav> via-rhine  15632   1 
svetoslav> 8139too16904   1 
svetoslav> mii 3800   0  [via-rhine 8139too]
svetoslav> dvb-core   51832   0  [via-rhine 8139too]
svetoslav> af_packet  14856   0  (autoclean)
svetoslav> radeon103036   3 

svetoslav> i don't have any dvb hardware
svetoslav> how can this happen ?

Different fix on 2.4.22.0.7mdk.  Basically there is a compat.c
file/module that "provides" crc32 for 2.4 kernels, but our kernel
already has crc32 modules.  I found in one of my machines a module
named compat.o (loaded) that as an asside tainted the kernel and
thought that my machine had been craked :p  After further
investigation found the problem.

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-tmb-2.4.22-0.5.2tmb_mdk

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

thomas> Ok,

Hi thanks a lot for the good work.

thomas> I didn't have time to add more features at this time,
thomas> or to fix the psaux, so that will have to wait for my next
thomas> kernel, I just rebuilt the whole set so people can use it...

psaux make my SMP system crash here, I just removed the patch (as told
in other mail).


Looking at your 2tmb patches.

thomas> %changelog
thomas> * Mon Aug 18 2003 Thomas Backlund <[EMAIL PROTECTED]> 2.4.22-0.5.2tmb_mdk
thomas> - drop psaux synaptics patch until I have time to fix it
thomas> - fix mod_dvb patch to use new build framework

I also fixed mod_dvb compat.c features, as it was interfering with
correct modules :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: lkml: Requested FAQ addition - Mandrake and partial-i686platforms

[Juan Quintela]

> "gc" == Guillaume Cottenceau <[EMAIL PROTECTED]> writes:

gc> Andrey Borzenkov <[EMAIL PROTECTED]> writes:
>> > Now we need to consider this as it should, e.g. with vanilla
>> > kernel anyway many mandrake additions are missing, but it's still
>> > important and probably should be at least documented.
>> 
>> put it another way - do we need this patch for 2.6? If yes, please, could you 
>> add it to contrib 2.6 RPM?

gc> I'd say yes but I guess Gwenole and/or Juan should rather answer
gc> that one.

without looking at the glibc source, we need it :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: new kernel alsa

[Juan Quintela]

> "danny" ==   <[EMAIL PROTECTED]> writes:

danny> On Wed, 20 Aug 2003, Austin wrote:
>> 
>> On 08/20/03 03:57:30, [EMAIL PROTECTED] wrote:
>> > On Tue, 19 Aug 2003, Austin wrote:
>> > 
>> > >
>> > > So a few comments:
>> > > 1. Kernel 2.6 alsa backport sucks.  Hard.
>> > It can also be due to one of the other ALSA patches inside mdk kernel. Can
>> > you just disable those and try, and do a diff on the rest to see what is
>> > different?
>> 
>> It sounds like that might be the problem.
>> I'm not 100% sure what you want me to do though.
>> Disable extraneous alsa patches in kernel spec, rebuild a new kernel and test 
danny> not sure if that is possible, you can only give the start patch number to 
danny> the apply_patches script. But you can just remove them from the patches 
danny> tarbal (it is in your SOURCES dir, IIRC 
danny> linux-q.tar.bz2) 

You can always try:

apply_patches --stop=ms01

apply_patches --start=za01-6

to skip all alsa patches.

Notice that alsa patches that we have are basically the only the ones
in alsa-0.9.6, or completely new aditions, i.e. basically no patches
to alsa code at all (just that their Makefiles/Config.in sucks big time).

danny> and then rebuild the kernel (check the patches you remove, some 
danny> might be required to let it build properly).
 
>> it.  I think I can do that.
>> But then diff what?
danny> o..I meant, if it still doesn't work, diff the unpacked alsa tarbal (it is 
danny> also in the patches file) against your 
danny> functional alsa download, to be sure there are no differences.

Yupp, and you can send me the diff to update it.

But first, please, test 2.4.22.0.7mdk, as I fixed a typo in request
module on our alsa patches.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] kernel 2.4.22.0.7mdk

[Juan Quintela]

Hi
all tmb patches of 5mdk.1tmb are integrated except:
- ps2_sypnatics (it just hangs my machine during harddrake if that
  patch is enabled)
- acl's for ext2/3: it failed to patch, and it were very late in the
  morning.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: /sbin/installkernel broken

[Juan Quintela]

> "j" == J A Magallon <[EMAIL PROTECTED]> writes:

j> Hi all...
j> I have tried to build latest -rc2, and installkernel can't find the
j> image to install:

j> + exec /sbin/installkernel 2.4.22-rc2-jam1m bzImage
j> /usr/src/linux-2.4.22-rc2-jam1m/System.map /boot
j> cat: bzImage: No such file or directory

Hi
I just did something stupid, and will make one option for
normal kernels, sorry.

It is needed for mandrake kernels, but only for some of them.
Fixed in next kernel.

Later, Juan.


j> This makes things work again:

j> --- installkernel.orig   2003-08-17 02:03:43.0 +0200
j> +++ installkernel2003-08-17 02:24:11.0 +0200
j> @@ -190,8 +190,6 @@
 
j> [[ -n $4 ]] && boot=$4 || boot=/boot
 
j> -cd $boot
j> -
j> [[ $AUTOREMOVE = "no" ]] && REMOVE=""
j> [[ $NOLINK = "yes" ]] && NOLINK=-n
 
j> Problem is that it leaves the script sitting at /boot and installkernel
j> is called with relative paths from arch/i386/boot.

j> Some change for specific mandrake things ? If it makes building standard
j> kernels fail...

j> TIA

j> -- 
j> J.A. Magallon <[EMAIL PROTECTED]>  \ Software is like sex:
j> werewolf.able.es \   It's better when it's free
j> Mandrake Linux release 9.2 (Cooker) for i586
j> Linux 2.4.22-rc1-jam1m (gcc 3.3.1 (Mandrake Linux 9.2 3.3.1-1mdk))


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: mod_dvb-1.0.0

[Juan Quintela]

> "steffen" == Steffen Barszus <[EMAIL PROTECTED]> writes:

steffen> Am Dienstag, 12. August 2003 23:08 schrieb Svetoslav Slavtchev:
>> Hi Thomas,
>> 
>> i uploaded mod_dvb-1.0.0 (and i think almost all my 2.4.22.0.2mdk patches)
>> 
>> to http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/for_tmb/
>> 
>> 
>> and the kernel team could also look into them :(

steffen> mod_dvb-1.0.0 is important since it would not make any sense to ship a PREx 
steffen> version. But I guess that applies to other patches on your site too. Has the 
steffen> devfsd.conf part of this go to devfsd package ? I would really love to see 
steffen> having dvb working of the box. 

steffen> vdr package is near to be finished now, some plugins for vdr (vcd, remote, 
steffen> dxr3, games) are ready too, other (dvd, mplayer, ??)  will follow. 

1.0.0 is in 5mdk to be released in short :p

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: mod_dvb-1.0.0

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

Hi

All this patches included.  Also the alsa rtc patch in the other mail.

Tip of the month:  compile your kernel with MODVERSION and you will
not forget the export-objs: lines :)

With respect to tmb patches, I checked mdk6.tmb5 patches. And the only
ones missing for integration/checking that are already in are:

+b0e0ed59677a808440101e218c767570  ZT15_supermount-ng_1.2.8.patch
+b5daa857e024298dea6749fa45d7be03  ZT25_BadRAM.patch
+1b47e85e0ec6a44a4711d6fee7ebc221  ZU00_tmb_at_iki.fi_addons.desc
+2e9d0592f67b2bb1a8e5c24d643fee03  ZU01_ir241_caddr_mask.patch
+0f8aaa14d6e98cd08fb6e977e76b78aa  ZU02_ir241_export_crc-3.patch
+216285beda3df510b908c7556ef66c2c  ZU03_ir241_iriap_skb_leak.patch
+585ad7ef2e506ce73a84a9d70eb677f8  ZU04_ir241_lmp_timer_race-2.patch
+d6037165b1b164778c88fec0efd11284  ZU05_ir241_secondary_rr.patch
+98a63fee709d8bd430d09b31aa7b0a94  ZU06_ir241_static_init.patch
+8453f75bff548b9b67509449f56f04c5  ZU07_ir241_usb_cleanup-4.patch
+5c0f410cd2414f22bc0060a647a2c9bd  ZU11_usb-ax8817x-2.4.21.patch
+4636a7cf29f69aa9682e217601ad58ea  ZU12_usb-ehci-2.4.21.patch
+117b6a0d4506be71082a35975dbc576b  ZU13_usb-hub-2.4.21.patch
+15d499a18210255d1f968577366e324f  ZU14_usb-kobil_sct-2.4.21.patch
+25ec9edce0abef34d1de5f63df2b6811  ZU15_usb-net_drivers-2.4.21.patch
+de20561daa3ff99d8371fdc5baee0b64  ZU16_usb-pl2303-01-2.4.21.patch
+ba02e1361a3153903e483c2b285fd0c4  ZU17_usb-pl2303-02-2.4.21.patch
+ad1340524069569723724281828f4e9d  ZU18_usb-rtl8150-2.4.21.patch
+cb70fc44d7dbecc174b013cf714d37b7  ZU19_usb-scanner-2.4.21.patch
+a56a3d641c91b30b63eb52536296f18e  ZU20_usb-serial-core-2.4.21.patch
+95cc88294113b4acafb75b30042057f6  ZU21_usb-speedtouch-2.4.21.patch
+77683df6c4b3114cfe75640990bf4fe9  ZU22_usb-storage-2.4.21.patch
+5467ed64266eb5aa1e94cfd50a857b9a  ZU23_usb-usbfs-2.4.21.patch
+59aefe3f7a62ef8a9dceb0d81e7a4cc5  ZU24_usb-vicam-2.4.21.patch
+cebbd76b0103407e89da06974c5e1f8b  ZU25_usb-visor-2.4.21.patch
+65a739229bf2d5588276c6e1298ebc9e  ZU31_bttv-20030625.patch
+385fc79caeefc5980094382323a8e584  ZU32_lirc_saa7134_kernel.patch
+c9a1d147937ab7a17634d420418967c5  ZU33_lirc_saa7134_3rdparty.patch
+1edc23381c63e83fbff754f19abbfb32  ZU42_gcc3.3.patch
+fc33d17c7b4d49df37fd1dbb2374854c  ZU43_ULL_fixes.patch
+8641356683284fa779fcfb1ce5b75a10  ZV00_tmb_at_iki.fi-experimental.desc
+d95f3df10becf4f4786e5c72ef865734  ZV01_sbp2-enable_addrem_hack.patch
+cd933468102d6501606bcf14490a79e0  ZV02_scsi_add_rem.patch

I will finish testing integrating them during the weekend/Monday.


Thanks a lot, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: mod_dvb-1.0.0

[Juan Quintela]

>>>>> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

svetoslav> Quoting Juan Quintela <[EMAIL PROTECTED]>:
>> >>>>> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]>
>> writes:
>> 
svetoslav> Hi Thomas,
svetoslav> i uploaded mod_dvb-1.0.0 (and i think almost all my 2.4.22.0.2mdk
>> patches)
>> 
svetoslav> to
>> http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/for_tmb/
>> 
>> 
>> Thanks, looking into it.
>> 
>> Later, Juan.

svetoslav> Thanks Juan, hope to see some of them in 4mdk

4mdk was already scheduled when I sent the mail, but 5mdk should
appear tomorrow with them :p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: mod_dvb-1.0.0

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

svetoslav> Hi Thomas,
svetoslav> i uploaded mod_dvb-1.0.0 (and i think almost all my 2.4.22.0.2mdk patches)

svetoslav> to http://varna.demon.co.uk/~svetlio/ruby-contrib/mdk-cook/for_tmb/


Thanks, looking into it.

Later, Juan.




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-utils-0.2-1mdk

[Juan Quintela]

> "buchan" == Buchan Milne <[EMAIL PROTECTED]> writes:

Done, thanks.

buchan> Charles A Edwards wrote:
>> On Mon,  4 Aug 2003 21:17:03 +0200 (CEST)
>> Frederic Lepied <[EMAIL PROTECTED]> wrote:
>> 
>> 
>>> Name: kernel-utils Relocations: (not
>>> relocateable) Version : 0.2   Vendor:
>>> MandrakeSoft Release : 1mdk  Build Date:
>>> Mon Aug  4 21:13:14 2003 Install date: (not installed)
>>> Build Host: hp6.mandrakesoft.com Group   : System/Kernel and
>>> hardwareSource RPM: (none) Size: 18745
>>> License: GPL
>>> Packager: Mandrake Linux Team 
>> 
>> 
>> With the creation of this rpm should not ksymoops be rebuilt so as not
>> to provide  kernel-utils
>> 
>> rpm -q --provides kernel-utils
>> perl(common)
>> kernel-utils = 0.2-1mdk
>> 
>> rpm -q --provides ksymoops
>> kernel-utils
>> ksymoops = 2.4.8-2mdk
>> 
>> rpm -q --requires initscripts
>> 
>> kernel-utils
>> 
>> At present
>> urpmi initscripts
>> One of the following packages is needed:
>> 1- ksymoops-2.4.8-2mdk.i586
>> 2- kernel-utils-0.1-1mdk.i586

buchan> And maybe kernel packages should now prerequire kernel-utils, since it
buchan> is no longer guaranteed that /sbin/installkernel is installed before a
buchan> kernel (as it was when it was in initscripts). Installing a kernel now
buchan> can easily result in no mods necessary to use the kernel, and no error
buchan> messages during installation.

buchan> Juan, this probably needs to be fixed sooner than later!

buchan> Regards,
buchan> Buchan

buchan> --
buchan> |--Another happy Mandrake Club member--|
buchan> Buchan MilneMechanical Engineer, Network Manager
buchan> Cellphone * Work+27 82 472 2231 * +27 21 8828820x202
buchan> Stellenbosch Automotive Engineering http://www.cae.co.za
buchan> GPG Key   http://ranger.dnsalias.com/bgmilne.asc
buchan> 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7

buchan> **
buchan> Please click on http://www.cae.co.za/disclaimer.htm to read our
buchan> e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
buchan> **


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: can taskfile eat data? (when was it first enabled in mdkkernels?)

[Juan Quintela]

> "svetoslav" == Svetoslav Slavtchev <[EMAIL PROTECTED]> writes:

svetoslav> Hi,

Hi
to my knowledge, you can only got IDE corruption with taskfile
when you are using it explicitely (i.e. programs that do funny
things with ioctl on the ide device).  With normal use, should
be no problems.

svetoslav> i'm tracking really strange file system corruption 
svetoslav> (both reiserfs & xfs) on soft-raid-5 and lvm
svetoslav> using 4 ibm drives as masters on HPT374

I don't know if you already do, but try to run memtes to be sure that
memory timings are ok, and run smartctl to be sure that disk are also
ok.

svetoslav> have i missed smth? when was it activated in the -mdk kernel ?
svetoslav> any pointers for debugging the fs corruption?

svetoslav> and about the corruption:
svetoslav> rpm -ivh kernel-2.4.22.x.mdk.src.rpm
svetoslav> for i in 1 2 3; do rpmbuild -ba kernel-2.4.spec;done
svetoslav> would end on the 2nd or 3rd run with smth like:
svetoslav> ..
svetoslav> linux-2.4.21.tar.bz2 obsolated header 
svetoslav> the archive seems brocken, you might want to try recoverring it with 
svetoslav> ..

run md5sum before and after the failure.  Yes, I know that it will be
cached in memory, attached program should help to empty the memory of your
machine.  Change the megs value until a value that will fit your
machine (assumed less than 2GB of RAM).

Later, Juan.



fillmem.c
Description: Binary data




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: lkml: Requested FAQ addition - Mandrake and partial-i686platforms

[Juan Quintela]

> "gc" == Guillaume Cottenceau <[EMAIL PROTECTED]> writes:

gc> Gwenole Beauchesne <[EMAIL PROTECTED]> writes:
>> On Wed, 13 Aug 2003, [koi8-r] "Andrey Borzenkov[koi8-r] "  wrote:
>> 
>> > Thread is quite interesting even if I do not fully understand it :)
>> 
>> There is no CMOV emulator. I simply patched kernel so that it reports VIA 
>> C3 as i586.

gc> They pretend the bug was in the glibc, but you always said it was
gc> kernel who was wrongly reporting C3 as a i686. Who's right?

History is quite long.

short sumary:

glibc is wrong, but fix glibc is very difficult.  It is easier
to workaround problem on kernel.

Long story:

Intel when defined the i686, make cmov instruction optional,
guess why there is a cmov flag in the cpuid flags:

quintela$ grep cmov /proc/cpuinfo 
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat 
pse36 mmx fxsr syscall mmxext 3dnowext 3dnow

All intel CPU's implement cmov (to my knowledge all i686 CPU's except
old Via C3 and I am not sure about Crusoe).  All AMD i686 class cpu
implement cmov.

kernel defines i686 to be the intel definition.

Now come gcc, and gcc defined i686 as the intel implementation (aka
with cmov instruction).  As cmov instruction is very good for the
compiler, gcc people don't want to define i686 without cmov.

Now what is the right definiton?

Obviously, teh most right definition is the kernel one, as that is as
the specification tels.

Now, what is the most useful definition?

Obviously also, the gcc one, as the generate code is better.

How to fix that?

a) kernel tell that i686 only for cpus that have cmov (workaround).
b) ld.so checks architecuter and flags, that works for ld.so, and is a
   better & more elegant solution.  gb told me that there is some
   problem with dlopen().

That is the state of the question as far as I know it.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-utils-1.1-1mdk

[Juan Quintela]

>>>>> "adam" == Adam Williamson <[EMAIL PROTECTED]> writes:

adam> On Wed, 2003-08-13 at 21:30, Juan Quintela wrote:
>> -=-=-=-
>> Name: kernel-utils Relocations: (not relocateable)
>> Version : 1.1   Vendor: MandrakeSoft
>> Release : 1mdk  Build Date: Wed Aug 13 22:23:49 2003
>> Install Date: (not installed)   Build Host: bi.mandrakesoft.com
>> Group   : System/Kernel and hardwareSource RPM: (none)
>> Size: 20197    License: GPL
>> Signature   : (none)
>> Packager: Juan Quintela <[EMAIL PROTECTED]>
>> URL : 
>> http://www.linux-mandrake.com/cgi-bin/cvsweb.cgi/soft/initscripts/mandrake/loader/
>> Summary : Small utils needed for the kernel
>> Description :
>> 
>> Utils needed to install/remove a kernel.  Also for updating bootloaders.
>> 
>> 
>> 
>> -=-=-=-
>> Juan Quintela <[EMAIL PROTECTED]> 1.1-1mdk
>> 
>> - Argh, upload wrong old 1.0 version.

adam> Given how much trouble Juan's having with this package, are we sure he's
adam> qualified to work on the kernel? ;)

Hi

When things begin to be the difference between:

my $kk = $1 if m/^default="?([^\t "]*)"?/;

and

my $kk = $1 if m/^default=(")?([^(\t ")]*)"?/;

and the more simple:

my $kk = $1 if m/^default=(\S+)/;

head begins to hurt :(

that was for the previous ones.

the 1.0 packages was a very, very old package that just happened to be
in the wrong directory when I updated the 0.8 one :(

Later, Juan.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-utils-0.5-1mdk

[Juan Quintela]

>>>>> "john" == John Keller <[EMAIL PROTECTED]> writes:

john> Juan Quintela wrote:
>> Name: kernel-utils Relocations: (not relocateable)
>> Version : 0.5       Vendor: MandrakeSoft

john> [...]

>> Juan Quintela <[EMAIL PROTECTED]> 0.3-1mdk

john> Hmm. Which version is canonical? (Sorry, it's just my nature to see these
john> things.)

Arghh, I did 3 internal versions for me, and forget to update the
changelog.  Anyways, I need to check, I thought that the changelog was
generated directly from CVS comments.

0.5 is the canonical one.

Later, Juan.




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-2.4.22-0.3mdk make xconfig fix

[Juan Quintela]

> "tim" == Tim Lee <[EMAIL PROTECTED]> writes:

tim> On line 1150 in scripts/tkgen.c, increasing the "limit" on
tim> tot_menu_num allows "make xconfig" to run fine. Like so:

tim> if ( ++tot_menu_num >= 150 )

well, it is a good idea  to change the size of the arrays to 150 also
:)

Fixed.

tim> A separate problem is that all the symlinks in the net/ipsec/alg/lib*
tim> directories are bad. I think in each Makefile.alg_*, there is a rule
tim> to re-symlink those directories.

Working on that for 5mdk.

Later, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.22.0.4mdk-1-1mdk

[Juan Quintela]

> "john" == John Keller <[EMAIL PROTECTED]> writes:

john> John Keller wrote:
>> Does this package address the broken symlinks? I forgot to update the
>> subject in my other note, but the problems I mentioned that didn't allow
john> me
>> to compile the kernel were for kernel-2.4.22.0.3mdk.

john> Grrr. I mean, "kernel-source...".

john> Sorry for all the excess blather surrounding my real question.

No.  But 5mdk will do.

Will release 5mdk tomorrow morning when:

- supermonut-ng is merged (yes, at least )
- that damn symlinks are fixed.

Sorry for the delay in both, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.22.0.1mdk-1-1mdk

[Juan Quintela]

>>>>> "austin" == Austin  <[EMAIL PROTECTED]> writes:

austin> On 08/08/2003 10:10:12 AM, Juan Quintela wrote:
>> -=-=-=-
>> Name: kernel-2.4.22.0.1mdk Relocations: (not

>> - remove low_latency patch, it hangs the system.

austin> Bummer.

Will be back, but after 9 hours trying to found why now fails (it
has been integrated since long, long ago), and were 7:00am, I decided
that I was a good idea to drop the patch and release the kernel (delay
was already big enough :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] nfs-utils-1.0.4-1mdk --> rpc.mountd crashes

[Juan Quintela]

>>>>> "buchan" == Buchan Milne <[EMAIL PROTECTED]> writes:

Sorry for the delay, but 1.0.5-1mdk should already do that.

Later, Juan.

buchan> Juan Quintela wrote:
>>>>>>> "stefan" == Stefan van der Eijk <[EMAIL PROTECTED]> writes:
>> 
>> 
>> Should be working now with 1.0.5, problem was upstream.
>> 

buchan> I think there is still a minor problem in packaging.

buchan> From the spec file, in %files clients:

buchan> %dir %{_localstatedir}/nfs
buchan> %dir %{_localstatedir}/nfs/state
buchan> %doc README
buchan> %dir %attr(700,rpcuser,rpcuser) /var/lib/nfs/statd

buchan> When I restarted nfslock service, rpc.statd would not start up:
buchan> Jul 23 19:36:14 bgmilne rpc.statd[18121]: open (/var/lib/nfs/state):
buchan> Permission denied

buchan> So, I chown'ed it rpcuser, and tried again, then:
buchan> Jul 23 19:36:52 bgmilne rpc.statd[18266]: mkdir (/var/lib/nfs/sm.bak):
buchan> Permission denied

buchan> So, I chown'ed rpcuser /var/lib/nfs

buchan> I remember having problems like this in the past (I am sure there is a
buchan> bugzilla entry somewhere on this ...), so can you solve this? Maybe having:

buchan> %dir %attr(700,rpcuser,rpcuser) %{_localstatedir}/nfs
buchan> is sufficient?

buchan> Or should it be mode 755 (as it is at present)?

buchan> Regards,
buchan> Buchan

buchan> --
buchan> |--Another happy Mandrake Club member--|
buchan> Buchan MilneMechanical Engineer, Network Manager
buchan> Cellphone * Work+27 82 472 2231 * +27 21 8828820x202
buchan> Stellenbosch Automotive Engineering http://www.cae.co.za
buchan> GPG Key   http://ranger.dnsalias.com/bgmilne.asc
buchan> 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7

buchan> **
buchan> Please click on http://www.cae.co.za/disclaimer.htm to read our
buchan> e-mail disclaimer or send an e-mail to [EMAIL PROTECTED] for a copy.
buchan> **


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] modutils-2.4.22-10mdk.

[Juan Quintela]

> "olivier" == Olivier Blin <[EMAIL PROTECTED]> writes:

>> Name: modutils Relocations: (not relocateable)
>> Version : 2.4.22Vendor: MandrakeSoft
>> Release : 10mdk.Build Date: Wed Jul 16 18:04:22 2003

olivier> Nice typo in release ;-)
olivier> (the dot)

Fixed and updated. I noticed the problem when I run rpmlint :p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] iptables-1.2.8-1mdk

[Juan Quintela]

>>>>> "oden" == Oden Eriksson <[EMAIL PROTECTED]> writes:

oden> onsdagen den 30 juli 2003 04.45 skrev Juan Quintela:
>> --=-=-=
>> Name: iptables Relocations: (not relocateable)
>> Version : 1.2.8 Vendor: MandrakeSoft
>> Release : 1mdk  Build Date: Wed Jul 30 04:31:35

oden> How did you manage to enable TARPIT support in iptables when the patch is not 
oden> applied in the latest Mandrake kernel?

oden> rpm -qlp iptables-1.2.8-1mdk.i586.rpm | grep TARPIT
oden> /lib/iptables/libipt_TARPIT.so

No idea, really, just did the default rebuild with new kernel.  Will
look at that later.

Later, Juan "officially old from today" Quintela.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] iptables-1.2.7a-3mdk

[Juan Quintela]

> "per" == Per Øyvind Karlsen <[EMAIL PROTECTED]> writes:


Hi
I have to recheck this, but I think that this Makefile was not
-j friendly.  It is possible that I should have put a comment
telling that.

per> - rebuild
per> - rm -rf $RPM_BUILD_ROOT at the beginning of %install, not in %prep
per> - use %make macro
per> - use %makeinstall_std macro

per> -make COPT_FLAGS="$OPT" LIBDIR=/lib all experimental
per> +%make COPT_FLAGS="$OPT" LIBDIR=/lib all experimental
 
Thanks, for the changes.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: enterprise kernel

[Juan Quintela]

> "ray" == Ray Carlino <[EMAIL PROTECTED]> writes:

Hi

ray> I just bought 8 new Dell servers and need to put Mandrake 9.1 or 9.2 on
ray> them ..
ray> The problem is they have 6GB Ram and the enterprise kernel is only built
ray> for 4GB.
ray> So as a suggestion can you start building the kernel with 64GB support?
ray> And second is there a config file of the enterprise kernel around that I
ray> can use to rebuild with 64GB support? I want all of the same options
ray> that are built in now but more memory..

Wow.  I guess that I am going to have to do it :p

Later, Juan.

/me decides to begin a collect to bougth a machine with more than 4GB
of memory for local testing :p

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.21.4mdk-1-1mdk

[Juan Quintela]

>>>>> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

thomas> From: "Juan Quintela" <[EMAIL PROTECTED]>
>> Name: kernel-2.4.21.4mdk   Relocations: (not relocateable)
>> Version : 1 Vendor: MandrakeSoft
>> Release : 1mdk  Build Date: Tue Jul 22 17:31:12
thomas> 2003

thomas> kernel-secure hangs at:
thomas> INIT: version 2.85 booting

thomas> standard kernel hangs with:
thomas> INIT: version 2.85 booting
thomas> INIT: PANIC: segmentation violation at 0x4008ce9a! Sleeping for 30
thomas> seconds...


thomas> kernel-(secure-)2.4.21.3mdk works as it should on this system...

Compiling 5mdk, that will be out in a couple of hours.

It just happens that at home, I had gcc-3.3.1-0.6mdk, and bi had
gcc-3.3.1-0.5mdk.  0.5mdk version miscompiles something, recompiling
with new compiler the 5mdk version.

Sorry for the inconvenience.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] nfs-utils-1.0.4-1mdk --> rpc.mountd crashes

[Juan Quintela]

>>>>> "stefan" == Stefan van der Eijk <[EMAIL PROTECTED]> writes:

Should be working now with 1.0.5, problem was upstream.

I am not sure if there is still a minor annoyance with local
imports/exports, but between different hosts, it is working without
any problem at all.

Later, Juan.

>> --=-=-=
>> 
>> * Wed Jul 16 2003 Juan Quintela <[EMAIL PROTECTED]> 1.0.4-1mdk
>> 
>> - remove patch5 (time.h) already included upstream.
>> - remove patch2 no-chroot (not needed after removing patch0).
>> - remove patch0 (drop privs) included better patch upstream.
>> - 1.0.4.
>> 
>> --=-=-=
>> 

stefan> I just updated this package, and rpc.mountd crashes on the second
stefan> request it gets:

stefan> Restart the NFS services:

stefan> [EMAIL PROTECTED] root]# service nfs stop
stefan> Stopping NFS mountd:[FAILED]
stefan> Stopping NFS daemon:[FAILED]
stefan> Stopping NFS services:  [  OK  ]
stefan> [EMAIL PROTECTED] root]# service nfs start
stefan> Starting NFS services:  [  OK  ]
stefan> Starting NFS daemon:[  OK  ]
stefan> Starting NFS mountd:[  OK  ]

stefan> check to see if rpc.mountd is running:

stefan> [EMAIL PROTECTED] root]# service nfs status
stefan> rpc.mountd (pid 3192) is running...
stefan> nfsd (pid 3181) is running...
stefan> 3180 (pid 3179) is running...
stefan> 3178 (pid 3177) is running...
stefan> 3174 (pid 3173) is running...
stefan> 3172 (pid ) is running...

stefan> on the remote system:
stefan> # ls /mirrors/cooker/SRPMS

stefan> check to see if rpc.mountd is still running:

stefan> [EMAIL PROTECTED] root]# service nfs status
stefan> rpc.mountd (pid 3192) is running...
stefan> nfsd (pid 3181) is running...
stefan> 3180 (pid 3179) is running...
stefan> 3178 (pid 3177) is running...
stefan> 3174 (pid 3173) is running...
stefan> 3172 (pid ) is running...

stefan> on the remote system:

stefan> # ls /mirrors/contrib/SRPMS
stefan> *ls: /mirrors/contrib/SRPMS: No such file or directory*

stefan> check to see if rpc.mountd is running:

stefan> [EMAIL PROTECTED] root]# service nfs status
stefan> *rpc.mountd is stopped*
stefan> nfsd (pid 3181) is running...
stefan> 3180 (pid 3179) is running...
stefan> 3178 (pid 3177) is running...
stefan> 3174 (pid 3173) is running...
stefan> 3172 (pid ) is running...

stefan> On my network this is reproduceable. rpc.mountd survives the first
stefan> request, the second request kills it. Anybody else see this behaviour?

stefan> regards,

stefan> Stefan

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] nfs-utils-1.0.4-1mdk --> rpc.mountd crashes

[Juan Quintela]

>>>>> "stefan" == Stefan van der Eijk <[EMAIL PROTECTED]> writes:

>> --=-=-=
>> 
>> * Wed Jul 16 2003 Juan Quintela <[EMAIL PROTECTED]> 1.0.4-1mdk
>> 
>> - remove patch5 (time.h) already included upstream.
>> - remove patch2 no-chroot (not needed after removing patch0).
>> - remove patch0 (drop privs) included better patch upstream.
>> - 1.0.4.
>> 
>> --=-=-=
>> 

stefan> I just updated this package, and rpc.mountd crashes on the second
stefan> request it gets:

Damn thing, will test here.  I tested it lightly before shipping, but
it looked as if it worked well.

Later, Juan.

stefan> Restart the NFS services:

stefan> [EMAIL PROTECTED] root]# service nfs stop
stefan> Stopping NFS mountd:[FAILED]
stefan> Stopping NFS daemon:[FAILED]
stefan> Stopping NFS services:  [  OK  ]
stefan> [EMAIL PROTECTED] root]# service nfs start
stefan> Starting NFS services:  [  OK  ]
stefan> Starting NFS daemon:[  OK  ]
stefan> Starting NFS mountd:[  OK  ]

stefan> check to see if rpc.mountd is running:

stefan> [EMAIL PROTECTED] root]# service nfs status
stefan> rpc.mountd (pid 3192) is running...
stefan> nfsd (pid 3181) is running...
stefan> 3180 (pid 3179) is running...
stefan> 3178 (pid 3177) is running...
stefan> 3174 (pid 3173) is running...
stefan> 3172 (pid ) is running...

stefan> on the remote system:
stefan> # ls /mirrors/cooker/SRPMS

stefan> check to see if rpc.mountd is still running:

stefan> [EMAIL PROTECTED] root]# service nfs status
stefan> rpc.mountd (pid 3192) is running...
stefan> nfsd (pid 3181) is running...
stefan> 3180 (pid 3179) is running...
stefan> 3178 (pid 3177) is running...
stefan> 3174 (pid 3173) is running...
stefan> 3172 (pid ) is running...

stefan> on the remote system:

stefan> # ls /mirrors/contrib/SRPMS
stefan> *ls: /mirrors/contrib/SRPMS: No such file or directory*

stefan> check to see if rpc.mountd is running:

stefan> [EMAIL PROTECTED] root]# service nfs status
stefan> *rpc.mountd is stopped*
stefan> nfsd (pid 3181) is running...
stefan> 3180 (pid 3179) is running...
stefan> 3178 (pid 3177) is running...
stefan> 3174 (pid 3173) is running...
stefan> 3172 (pid ) is running...

stefan> On my network this is reproduceable. rpc.mountd survives the first
stefan> request, the second request kills it. Anybody else see this behaviour?

stefan> regards,

stefan> Stefan

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk

[Juan Quintela]

> "gwenole" == Gwenole Beauchesne <[EMAIL PROTECTED]> writes:

gwenole> On Fri, 18 Jul 2003, Stefan van der Eijk wrote:
>> Otherwise we'll have a dead symlink in /usr/lib, which points to the .so 
>> symlink in /lib.

gwenole> Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so 
gwenole> symlinks. And I insist on %{_lib} & %{_libdir}. I had fixed that for lib64 
gwenole> but this magically vanished.

>> Any objections to updating xfsdump to 2.2.3?

No, I was waiting fro the symlink isue to be fixed.  I had the update
of the rest of the things.

gwenole> I don't know, kernel people will answer. And I suppose Vincent already 
gwenole> issued an update to 2.2.3.


>> > BuildRequires:libattr-devel
>> > BuildRequires:libdm-devel
>> > BuildRequires:libext2fs-devel
>> > BuildRequires:libxfs-devel

gwenole> Always BuildRequires: -devel forms only, not lib-devel.

ok, changing that.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] dmapi-2.0.5-3mdk

[Juan Quintela]

> "stefan" == Stefan van der Eijk <[EMAIL PROTECTED]> writes:

>>> Otherwise we'll have a dead symlink in /usr/lib, which points to
>>> the .so symlink in /lib.
>>> 
>> 
>> Then fix the symlink in %{_libdir}. Don't populate /%{_lib} with .so
>> symlinks.
>> 
stefan> Fine with me, as long as xfsdump will build.

>> And I insist on %{_lib} & %{_libdir}. I had fixed that for lib64 but
>> this magically vanished.
>> 
stefan> Yes, I agree. Sorry about that.

>>> Any objections to updating xfsdump to 2.2.3?
>>> 
>> 
>> I don't know, kernel people will answer. And I suppose Vincent
>> already issued an update to 2.2.3.
>> 
>> 
 BuildRequires:libattr-devel
 BuildRequires:libdm-devel
 BuildRequires:libext2fs-devel
 BuildRequires:libxfs-devel
 
>> 
>> Always BuildRequires: -devel forms only, not lib-devel.
>> 
stefan> Sure, but:

ok, will fix in teh same batch.

/me decides to spend the rest of the evening recompiling all his
packages.

/me thinks that this is optimist.

stefan> $ urpmq attr-devel
stefan> no package named attr-devel

stefan> $ urpmq dm-devel
stefan> no package named dm-devel

stefan> $ urpmq ext2fs-devel
stefan> no package named ext2fs-devel

stefan> $ urpmq xfs-devel
stefan> no package named xfs-devel

stefan> I understand where this is coming from, and I agree that it needs to
stefan> be done. But I don't think that it needs to be brought up in this
stefan> discussion. I'm getting the feeling that somebody is looking for
stefan> something to pick on...

stefan> I suggest:

stefan> *  rpmlint is adjusted to warn about (& enforce?) this on uploads;
stefan> * a document is written describing these changes so this can be
stefan> finalized into some sort of  guideline / policy. So people can
stefan> read it through, understand how it works and how it should be
stefan> implemented in the packages;


There is a document:

http://people.mandrakesoft.com/~gc/

stefan> For instance: I don't understand how the mklib stuff works and how I
stefan> should fix the rpmlint errors I get on the topic.

Just fixed it for dmapi, it is trivial:

%define lib_name_orig %mklibname dm

instead of

%define lib_name_orig libdm

Rule of thumb:
- when you have a problem of that kind, look for a package maintained
  by gb about how it is done there :p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.21.3mdk-1-1mdk

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

Hi

thomas> It works 
thomas> All kernels testbooted with 2 systems:
thomas> - one nForce2 system with 1GB ram (running enterprise now...)
thomas> - ond dual P2-333 with 256MB ram (running secure now...)

thomas> Way to go Juan!!
thomas> I would but you a case of beer if you would live closer... ;-)

worse thing is that the change was trivial:

s/&//

just that I missaplied a patch (finding where was the problem).



thomas> Only downside (for now) is that NTFS support is disabled...
thomas> (yeah, I saw the NTFS build error listing :-( ... )
thomas> But for now I'm happy...
thomas> Now I have a nice kernel to start patching ;-)

Nice.  Will update NTFS in the near future (just that I don't have any
machine with NTFS at all).

If someone has a small filesystem with it that can make available
(10-20MB), I will be happy to download.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel-2.4.21.2mdk-1-1mdk

[Juan Quintela]

>>>>> "warly" == Warly  <[EMAIL PROTECTED]> writes:

warly> "Thomas Backlund" <[EMAIL PROTECTED]> writes:
>> From: "Juan Quintela" <[EMAIL PROTECTED]>
>>> --=-=-=
>>> Name: kernel-2.4.21.2mdk   Relocations: (not
>> relocateable)
>>> Version : 1 Vendor: MandrakeSoft
>>> Release : 1mdk  Build Date: Tue Jul  1
>> 04:04:26 2003
>>> 
>> 
>> Could someone _please_ remove theese from Cooker main,
>> so that Juan's new kernels actually gets uploaded...
>> and reupload the correct one...
>> 
>> (and yes... the *doc* too since they come from the kernel2.4-marcelo,
>> and not from the MDK kernel...)
>> 
>> kernel-BOOT-2.4.21-0.rc1.1mdk-1-1mdk.i586.rpm
>> kernel-BOOT-2.4.21-0.0.1mdk-1-1mdk.i586.rpm
>> kernel-enterprise-2.4.21-0.rc1.1mdk-1-1mdk.i586.rpm
>> kernel-enterprise-2.4.21-0.0.1mdk-1-1mdk.i586.rpm
>> kernel-secure-2.4.21-0.rc1.1mdk-1-1mdk.i586.rpm
>> kernel-secure-2.4.21-0.0.1mdk-1-1mdk.i586.rpm
>> kernel-smp-2.4.21-0.rc1.1mdk-1-1mdk.i586.rpm
>> kernel-smp-2.4.21-0.0.1mdk-1-1mdk.i586.rpm
>> kernel-source-2.4.21-1mdk.i586.rpm
>> kernel-2.4.21-0.0.1mdk-1-1mdk.i586.rpm
>> kernel-doc-html-2.4.21-2mdk.i586.rpm
>> kernel-doc-pdf-2.4.21-2mdk.i586.rpm
>> kernel-doc-ps-2.4.21-2mdk.i586.rpm
>> kernel-doc-2.4.21-1mdk.i586.rpm

warly> I do not find the kernel-doc-{html,ps,pdf} for the latest
warly> kernel-2.4.21.2mdk, do they exist?

No, they are a pain in the ass to build.  Only build for marcelo
kernel (they are the same, and then I only need to build them once
each moon).

Later, Juan.

warly> -- 
warly> Warly


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: [CHRPM] kernel2.4-marcelo-2.4.21-2mdk

[Juan Quintela]

>>>>> "david" == David Walser <[EMAIL PROTECTED]> writes:

david> Is kernel-linus2.4-2.4.21-0.pre7.1mdk.i586.rpm going to be removed from the 
mirror then?
david> Juan Quintela wrote:

Yes.

>> --=-=-=
>> Name: kernel2.4-marceloRelocations: (not relocateable)
>> Version : 2.4.21Vendor: MandrakeSoft
>> Release : 2mdk  Build Date: Fri Jun 20 00:02:47 2003
>> Install date: (not installed)   Build Host: bi.mandrakesoft.com
>> Group   : System/Kernel and hardwareSource RPM: (none)
>> Size    : 28665589 License: GPL
>> Packager: Juan Quintela <[EMAIL PROTECTED]>
>> URL : http://www.kernel.org/
>> Summary : The Linux kernel (the core of the Linux operating system).
>> Description :
>> 
>> The kernel package contains the Linux kernel (vmlinuz), the core of your
>> Mandrake Linux operating system.  The kernel handles the basic functions
>> of the operating system:  memory allocation, process allocation, device
>> input and output, etc.
>> 
>> Exclusivearch: i386 
>> --=-=-=
>> 
>> * Sat Jun 14 2003 Juan Quintela <[EMAIL PROTECTED]> 2.4.21-1mdk
>> 
>> - 2.4.21 final.
>> 
>> --=-=-=
>> 
>> --=-=-=
>> 
>> --=-=-=
>> 


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: why is PF_MEMDIE removed from mdk kernel?

[Juan Quintela]

> "dany" ==   <[EMAIL PROTECTED]> writes:

dany> Juan,
dany> I'm working a bit on new kernel-multimedia again and noticed you removed 
dany> PF_MEMDIE from the mdk kernel. This may cause a task not to die under OOM?
dany> According to this, you agreed to that:
dany> http://www.cs.helsinki.fi/linux/linux-kernel/2003-01/1165.html

dany> Although, I guess this situation is not likely to occur.

Hi
PF_MEMDIE should be back, notice that the problem is that:
a- the damn thing should be commented in the kernel (It is needed).
b- I got it from AA patches, and anyways Andrea commented out that
   part of the kernel, it uses a completely different aproach.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: NEW Testkernel...

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

thomas> This is a the mdk standard kernel linux-2.4.21-0.13mdk + my changes:
thomas> http://www.iki.fi/tmb/Cooker/linux-2.4.21-0.13mdk-TmB.tar.bz2

thomas> Just  unzip/untar it to / and run the included Install, and reboot...

thomas> Here is the file that shows changes from linux-2.4.21-0.13mdk
thomas> http://www.iki.fi/tmb/Cooker/linux-2.4.21-0.13mdk-TmB_2.diff.bz2

I have been completely unable to reach this files in the last 2 days
:(

If you can send me the diff, I can try to integrate :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: New Testkernel for SMP...

[Juan Quintela]

> "todd" == Todd Lyons <[EMAIL PROTECTED]> writes:

Hi

>> For the APIC routing all interrupts to only one CPU, it is not normal.

todd> I think that's what people are bugging about in the Cooker list at the
todd> moment.  I never noticed it until someone in the list mentioned it.  The
todd> complaint is that it's impacting performance, I personally have not seen
todd> anything as a result of it.

If you have lots of interrupts (think for instance of a network
server), you will notice the drop in performance :(

>> Notice that for P4, it is normal, as some designer decided that this
>> was the right thing to do :(  

todd> Hmmm, so it's done for the P4 like that at the hardware level?
todd> Interesting.  Thanks for the 

In the P4 only way to fix it is to spread the interrupts by hand
between the processors.  Dual Pentium (

[Cooker] Re: New Testkernel for SMP...

[Juan Quintela]

> "todd" == Todd Lyons <[EMAIL PROTECTED]> writes:

Hi

>> /proc/interrupts

todd> CPU0   CPU1   
todd> 0:7192998  0IO-APIC-edge  timer
todd> 1:484  0IO-APIC-edge  keyboard
todd> 2:  0  0  XT-PIC  cascade
todd> 8:  1  0IO-APIC-edge  rtc
todd> 9:  0  0   IO-APIC-level  acpi
todd> 12:   5694  0IO-APIC-edge  PS/2 Mouse
todd> 15: 60  0IO-APIC-edge  ide1
todd> 17:  88296  0   IO-APIC-level  eth0
todd> 19: 185482  0   IO-APIC-level  ida0
todd> NMI:  0  0 
todd> LOC:71933037193301 
todd> ERR:  0
todd> MIS:  0

Damn thing, that is pretty wrong :(

>> /var/log/dmesg
todd> (Note that I tried passing apic=on with no difference)

I assume that you mean acpi=on acpi!=apic.  Blame intel for no
imagination.

todd> ACPI: RSDP (v000 COMPAQ ) @ 0x000f4f90
todd> ACPI: RSDT (v001 COMPAQ MICRO0.2) @ 0x17ffc000
todd> ACPI: FADT (v001 COMPAQ MICRO0.2) @ 0x17ffc040
todd> ACPI: MADT (v001 COMPAQ 0083 0.2) @ 0x17ffc100
todd> ACPI: SSDT (v001 COMPAQ SSDT 0.1) @ 0x17fff800
todd> ACPI: DSDT (v001 COMPAQ DSDT 0.1) @ 0x

This is not official, blah, blah.  I just happen to hate Compaq BIOS,
they always give me problems :(  They are one of the worst offenders
of, it isi work with Windows, it is good :(

todd> ACPI: BIOS passes blacklist
todd> ACPI: Local APIC address 0xfee0
todd> ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
todd> Processor #0 Pentium(tm) Pro APIC version 16
todd> ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
todd> ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
todd> ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] enabled)

ACPI is enabled.

todd> Processor #3 Pentium(tm) Pro APIC version 16

You have no gurantees that processors will be numbered correlatively.

todd> ENABLING IO-APIC IRQs
todd> init IO_APIC IRQs
todd> IO-APIC (apicid-pin) 8-0, 8-2, 8-16, 8-17, 8-18, 8-19, 8-20, 8-21,
todd> 8-22, 8-23, 8-24, 8-25, 8-26, 8-27, 8-28, 8-29, 8-30, 8-31, 8-32, 8-33,
todd> 8-34 not connected.
todd> ..TIMER: vector=0x31 pin1=-1 pin2=0
todd> ...trying to set up timer (IRQ0) through the 8259A ...
todd> . (found pin 0) ...works.
todd> number of MP IRQ sources: 15.
todd> number of IO-APIC #8 registers: 35.
todd> testing the IO APIC...

todd> IO APIC #8..
todd>  register #00: 0800
todd> ...: physical APIC id: 08
todd>  register #01: 00220011
todd> ... : max redirection entries: 0022
todd> ... : PRQ implemented: 0
todd> ... : IO APIC version: 0011
todd>  register #02: 
todd> ... : arbitration: 00
todd>  IRQ redirection table:
todd> NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
todd> 00 001 01  000   0   01131
todd> 01 001 01  000   0   01139
todd> 02 000 00  100   0   00000
todd> 03 001 01  000   0   01141
todd> 04 001 01  000   0   01149
todd> 05 001 01  000   0   01151
todd> 06 001 01  000   0   01159
todd> 07 001 01  000   0   01161
todd> 08 001 01  000   0   01169
todd> 09 001 01  000   0   01171
todd> 0a 001 01  000   0   01179
todd> 0b 001 01  000   0   01181
todd> 0c 001 01  000   0   01189
todd> 0d 001 01  000   0   01191
todd> 0e 001 01  000   0   01199
todd> 0f 001 01  000   0   011A1
todd> 10 000 00  100   0   00000
todd> 11 000 00  100   0   00000
todd> 12 000 00  100   0   00000
todd> 13 000 00  100   0   00000
todd> 14 000 00  100   0   00000
todd> 15 000 00  100   0   00000
todd> 16 000 00  100   0   00000
todd> 17 000 00  100   0   00000
todd> 18 000 00  100   0   00000
todd> 19 000 00  100   0   00000
todd> 1a 000 00  100   0   00000
todd> 1b 000 00  100   0   00000
todd> 1c 000 00  100   0   00000
todd> 1d 000 00  100   0   00000
todd> 1e 000 00  100   0   00000
todd> 1f 000 00  100   0   00000
todd> 20 000 00  100   0   00000
todd> 21 000 00  100   0   00000
todd> 22 000 00  100   0   00000
todd> IRQ to pin mappings:
todd> IRQ0 -> 0:0
todd> IRQ1 -> 0:1
todd> IRQ3 -> 0:3
todd> IRQ4 -> 0:4
todd> IRQ5 -> 0:5
todd> IRQ6 -> 0:6
todd> IRQ7 -> 0:7
todd> IRQ8 -> 0:8
todd> IRQ9 -> 0:9
todd> IRQ10 -> 0:10
todd> IRQ11 -> 0:11
todd> IRQ12 

[Cooker] Re: [CHRPM] kernel-2.4.21.0.pre4.5mdk-1-1mdk

[Juan Quintela]

> "chmouel" == Chmouel Boudjnah <[EMAIL PROTECTED]> writes:

chmouel> Thomas Backlund <[EMAIL PROTECTED]> writes:
>> Viestissä Sunnuntai 9. Helmikuuta 2003 01:17, Chmouel Boudjnah kirjoitti:
>>> --=-=-=
>>> Name: kernel-2.4.21.0.pre4.5mdkRelocations: (not
>>> relocateable) Version : 1 Vendor:
>>> MandrakeSoft Release : 1mdk  Build Date: Sat
>> 
>> ARGH
>> 
>> you forgot this "patch" from pre4.3mdk in defconfig-secure
>> - Disable (CONFIG_GRKERNSEC_PAX_PAGEEXEC)
>> 
>> (it was also left out in pre4.4mdk ...)

chmouel> i have no idea why Juan got it integred again, i am pretty sure it was
chmouel> removed by pre4.3mdk. Juan ?


Arghh, just that I had to remerge a lot of .config, and
that was lost in the noise :(

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm fails in no /dev/loop

[Juan Quintela]

> "rolf" == Rolf Pedersen <[EMAIL PROTECTED]> writes:

rolf> guran wrote:
>> Hi
>> [root@localhost Documents]# urpmi
>> kernel-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm
>> kernel-BOOT-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm
>> kernel-doc-2.4.21-0.pre4.3mdk.i586.rpm
>> kernel-doc-2.4.21-0.pre4.3mdk.i586.rpm
>> kernel-secure-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm
>> Some package requested cannot be installed:
>> kernel-doc-2.4.21-0.pre4.3mdk.i586
>> do you agree ? (Y/n)
>> installing kernel-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm
>> kernel-doc-2.4.21-0.pre4.3mdk.i586.rpm
>> kernel-secure-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm
>> kernel-BOOT-2.4.21.0.pre4.3mdk-1-1mdk.i586.rpm
>> Preparing...
>> ##
>> 
>> 1:kernel-2.4.21.0.pre4.3mdk##
>> mke2fs 1.32 (09-Nov-2002)
>> mount: could not find any device /dev/loop#
>> mke2fs 1.32 (09-Nov-2002)
>> mount: could not find any device /dev/loop#
>> There was an error when generating initrd try to do a :
>> /sbin/mkinitrd /boot/initrd-2.4.21pre4-3mdk.img 2.4.21pre4-3mdk
>> and see the errors
>> look like there was a problem, the default vmlinuz version is not the same
>> of the initrd
>> which mean you have a mdk kernel and not a mdk initrd you may go in trouble
>> 2:kernel-doc ##
>> 
>> 3:kernel-secure-2.4.21.0.pre4.3mdk##
>> mke2fs 1.32 (09-Nov-2002)
>> mount: could not find any device /dev/loop#
>> mke2fs 1.32 (09-Nov-2002)
>> mount: could not find any device /dev/loop#
>> There was an error when generating initrd try to do a :
>> /sbin/mkinitrd /boot/initrd-2.4.21pre4-3mdksecure.img 2.4.21pre4-3mdksecure
>> and see the errors
>> look like there was a problem, the default vmlinuz version is not the same
>> of the initrd
>> which mean you have a mdk kernel and not a mdk initrd you may go in trouble
>> 
>> 4:kernel-BOOT-2.4.21.0.pre4.3mdk##
>> [root@localhost Documents]# /sbin/mkinitrd
>> /boot/initrd-2.4.21pre4-3mdk.img 2.4.21pre4-3mdk
>> mke2fs 1.32 (09-Nov-2002)
>> mount: could not find any device /dev/loop#
>> Can't get a loopback device
>> regards
>> guran
>> 
rolf> I ran into this 'could not find any device /dev/loop#' and similar
rolf> failure to mkinitrd on a kernel install once.  Seems what I did was
rolf> modprobe loop and mkinitrd to solve.  Don't know why this was needed.

Just that my aes.o module got in the middle and broke.

It is working back in new 2.4.21-pre4q4.

If you really don't want to reboot your machine in one old kernel for
installing new one:
- install new kernel (it will fail in the same way than this one)
- insmod /lib/modules/2.4.21pre4-4mdk/kernel/drivers/misc/aes.o
- insmod /lib/modules/2.4.21pre4-4mdk/kernel/drivers/block/loop.o

urpme new kernel
urpmi new kernel and everything should work again :p

(this is from memory, you should have to fix the right patch for your
type of kernel )

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on mediachange wth busy files

[Juan Quintela]

> "andrey" == Andrey Borzenkov <[EMAIL PROTECTED]> writes:

>> >> Nope, you need it to have a working: extract cd, change cd,
>> >>make it working.
>> >>
>> 
borzenkov> Nope, it is just an accidental side effect. Put_inode (as
borzenkov> it was) is buggy and not needed.
>> 
>> Are you sure?  We are using put_inode() to _never_ cache inodes of
>> supermounted media after use.  Supermount relies on that behaviour.

andrey> To clarify - inode caching is not a problem because supermount never
andrey> reuse inodes. On first lookup new dentry/inode pair is allocated,
andrey> after media change inode is stale, on next lookup d_revalidate returns
andrey> false and we allocate new dentry/inode pair. (directories is 
andrey> special case but it does not change general rule). We never lookup
andrey> or reuse old inode. using force_delete just purges them from cache
andrey> faster. 

This is a nice theory, but is the thing that is failing :(

For some reason, d_revalidate() is not given the correct values :(

Just now I am having this problem when I switch CD's with ejects in
the midle of some operation:

[root@besta root]# ls /mnt/cdrom/
ls: /mnt/cdrom/libncurses5-5.2-16mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libnetpbm9-9.10-6mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libnewt0.50-0.50.31-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libnspr4-4.1-6mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libnss3-3.2.1-6mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/liboaf0-0.6.6-3mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libogg0-1.0-0.rc2.1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libopenssl0-0.9.6b-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpcap0-0.6.2-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpcre0-3.5-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpilot-link4-0.9.5-3mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpng2-1.0.12-2mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpng2-devel-1.0.12-2mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libprelude0-0.4.2-6mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpspell4-0.12.2-2mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libptal0-0.8-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libpth14-1.4.0-2mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libqt2-2.3.1-14mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libqtcups2-2.1-13mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/librep-0.14-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/librsvg1-1.0.1-1mdk.i586.rpm: No such file or directory
ls: /mnt/cdrom/libsafe-2.0.5-5mdk.i586.rpm: No such file or directory


I think that it just has happened that inode numbers of the old sub
mounted media are just given the same number than the old used ones,
but I don't know what that is happening 

(yes, there are not rpm on this root directory, it is a installation
disk of Mandrake).

borzenkov> - fix the last case of improper ESTALE
>> 
>> I thought this one should been fixed, will look at it.

andrey> No, the attached patch really fixes it. It disconnects busy dentries
andrey> from fs tree. they go away when process that holds them open goes away.


I will like this patch, just not sure about the handling of the
sb->s_root dentry.  We were assuming (for some reason I don't
remember) than the root dentry is always there.  I think that it was
to be able to not mount the subfs each time that somebody did a stat
of /mnt/cdrom.

andrey> It is as much as I expect to go into update for 9.0 (assuming no
andrey> serious bugs is found). For 9.1 if time permit see later.

borzenkov> - some more vague ideas
>> 
>> Humm, that is really vague.

andrey> No more.

andrey> - keep list of struct files; close subfs files on media change to
andrey> allow clean umount; mark supermount files as dead; provide mount
andrey> option on_media_change={TERM,KILL,EIO,ESTALE} to respectively TERM or
andrey> KILL owners or just return EIO/ESTALE on subsequent read/write and
andrey> let them handle it.

Only sane way to handle it is -EIO/ESTALE.  

andrey> - add strict_media_change option to always check; intended for slow
andrey> writable media like floppy to catch media change as soon as possible
andrey> to avoid overwriting of newly inserted floppy.

andrey> - add user interface to umount subfs; it is pretty trivial to
andrey> implement as remount option but I am not sure about permissions.
andrey> Intentional use is approximately

andrey> mount -o remount,release /mnt/floppy
andrey> format /dev/fd
andrey> mkfs /dev/fd
andrey> cp /vmlinuz /mnt/floppy

andrey> Not sure how really useful it is but it is quite trivial to implement.

andrey> - document the whole stuff

Yep, I did one beggining, but just stopped due to other things.

I have just thinkig about a way to improve the check_media mess.
- s/int s_media_changed/atomic_t s_media_changed/
  that way, we are not loosin

[Cooker] Re: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on mediachange wth busy files

[Juan Quintela]

> "chmouel" == Chmouel Boudjnah <[EMAIL PROTECTED]> writes:

chmouel> Juan you take care to integrate them ,

will be there, integrating them in the kernel for updates.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: PATCH: 2.4.21-0.pre3.1mdk: supermount - fix ESTALE on mediachange wth busy files

[Juan Quintela]

> "borzenkov" == Borzenkov Andrey <[EMAIL PROTECTED]> writes:

borzenkov> Folks, unfortunately patch in 9.0/updates (or supermount/2.4.20) is buggy;
borzenkov> it has the same bug as in 9.0.
>> 
>> >> BTW, I just integrated all your patches in kernel for updates (will
>> >> be in next cooker kernel).  I just didn't delete put_inode() as
>> >> your patch does.
>> 
andrey> Strange. For all I can tell it was the exact reason for
>> "disappearing
andrey> files".
>> 
>> Nope, you need it to have a working: extract cd, change cd, make it
>> working.
>> 

borzenkov> Nope, it is just an accidental side effect. Put_inode (as
borzenkov> it was) is buggy and not needed.

Are you sure?  We are using put_inode() to _never_ cache inodes of
supermounted media after use.  Supermount relies on that behaviour.

borzenkov> ESTALE was my fault, I did not expect that the same
borzenkov> superblock is reused on remount with busy files. The
borzenkov> attached patch plugs the hole (reinitialize
borzenkov> s_media_changed) until I find a proper fix.

Just saw that :(  We have to reuse the superblock because we need a
place to store the generation value.

borzenkov> Also patch does

borzenkov> - "mode" parameter was forgotten for ext2

Applied.

borzenkov> - move setting of s_media_changed to where it belongs - check_disk_change

Done.

borzenkov> - add MS_SUPERMOUNTED flag for future use

Done but see below.

borzenkov> - use MS_SUPERMOUNTED to properly respect reference count on CD eject
borzenkov> instead of blindly disabling it

Nice, adopted.

borzenkov> - "self destroying" message is back, it is fixed for supermount and we
borzenkov> should not hide errors for other cases.

It was just a hack :p


borzenkov> cd /mnt/cdrom/foo
borzenkov> eject
borzenkov> ls /mnt/cdrom

borzenkov> will show /mnt/cdrom/foo as ESTALE. It is because d_invalidate never
borzenkov> invalidates busy directory. I think I know how to fix it.

will look at that.

borzenkov> TODO

borzenkov> - really fix ejecting with busy files

It shouldn't be that problem, we are supposed to have the door closed
if we have busy files.  If you are using a floppy that don't have a
locking mechanism and you retire the floppy in the middle of a write,
well, you get what you asked for (an error).

borzenkov> - fix the last case of improper ESTALE

I thought this one should been fixed, will look at it.

borzenkov> - some more vague ideas

Humm, that is really vague.

later, Juan.

Now some comments about the patch:

+#if defined(CONFIG_SUPERMOUNT) || defined(CONFIG_SUPERMOUNT_MODULE)
+#define MS_SUPERMOUNTED (1<<29)
+#endif

That is a bad idea, changing it to (1 <<17) next unused value,
MS_ACTIVE & MS_NOUSER are supposed to be very, very big numbers with
respect to the rest of the flags.


diff -ru -x '*~' -x '*.[oas]' -x '*.[oa].flags' -x .depend -x .config -x modversions.h 
-x '*.ver' -x autoconf.h -x version.h /usr/src/linux-2.4.21-0.pre3.1mdk/fs/inode.c 
linux-2.4.21-0.pre3.1mdk/fs/inode.c
--- /usr/src/linux-2.4.21-0.pre3.1mdk/fs/inode.c2003-01-16 19:18:14.0 
+0300
+++ linux-2.4.21-0.pre3.1mdk/fs/inode.c 2003-01-27 23:04:24.0 +0300
@@ -704,9 +704,6 @@
int res = 0;
 
if (sb) {
-#if defined(CONFIG_SUPERMOUNT) || defined(CONFIG_SUPERMOUNT_MODULE)
-   sb->s_media_changed = 1;
-#endif
res = invalidate_inodes(sb);
drop_super(sb);
}

We lacked here also a shrink_dcache_sb(sb); :p


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Supermount in MDK 9.0

[Juan Quintela]

> "palmer," == Palmer, Hilary <[EMAIL PROTECTED]> writes:

palmer,> I loaded 9.0 on my system at home, but I noticed if I start copying a lot of
palmer,> data off of a CD, SuperMount seems to drop the CD.  It will say that it
palmer,> doesn't have access to any of the files after the few that are copied.  Then
palmer,> I need to eject and reinsert the CD to see anything on it again.

palmer,> If I do not use the SuperMount feature and mount the CD-ROM manually it
palmer,> works fine.

palmer,> Any ideas?

palmer,> Thanks,
palmer,> Hil

Hi
could you test 2.4.19-23mdk that will appears shortly in:

http://people.mandrakesoft.com/~quintela/updates/9.0?

Thanks, Juan.



-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: kernel2.4.20-0.1 and supermount

[Juan Quintela]

> "eric" == Eric Piel <[EMAIL PROTECTED]> writes:

eric> Hello
eric> I still have troubles with supermount, even in kernel2.4.20-0.1. It
eric> has never correctly worked in 2.4.19 but was always fine with 2.4.18.

eric> The problems are that if I access a file (like listenning to a mp3
eric> with xmms) then after few seconds all the other files are missing. I
eric> have to eject the cdrom and reload it to listen to the next mp3...

eric> Does anyone has the same problem? I think it's a bug in the supermount
eric> code (which seems quite hard to maintain) but may be it's just a
eric> configuration problem so here is my fstab line:
eric> none /mnt/cdrom supermount
eric> dev=/dev/hdc,fs=iso9660,ro,--,iocharset=iso8859-15 0 0

Sorry for the delay, please test the kernel for updates that will
appear in:

http://people.mandrakesoft.com/~quintela/updates/9.0

(23mdk).

Later, Juan.




-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Fwd: PATCH: 2.4.20-2mdk: supermount combined patch

[Juan Quintela]

> "dan" == Dan Clayton <[EMAIL PROTECTED]> writes:

dan> On Friday 03 January 2003 03:27 pm, Danny Tholen wrote:
>> Finally, Andrey send me a fix for supermount.
>> I will probably also merge this with my kernel on the club, unless
>> an official update is released?
>> 
>> happy new year to you all:)
>> 
>> Danny

dan> I there a version of   2.4.20-2mdk kernal on the club or elsewhere 
dan> that wirks with 9.0 instead of cooker. I can find a lot of things 
dan> easitly but not much for kernel updates for 9.0.

Look in a couple of hours in:

If you found a way to broke supermount, I am interested in knowing how
:p


http://people.mandrakesoft.com/~quintela/updates/9.0

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: Konqueror vs. supermount or "my CD is snapping on me!"

[Juan Quintela]

> "andrey" == Andrey Borzenkov <[EMAIL PROTECTED]> writes:

andrey> this applies to 9.0 + security fixes, I cannot test current cooker. Sorry :(
andrey> Konqueror is using polling (stat call) to check for directory updates, that 
happens appr. every second. When it is used with supermount, it prevents user from 
opening tray, as soon as you manage open it konqueror does next stat and tray is 
(automatically) closed again. this happens even if you changed directory - as a test

andrey> fire up konqueror
andrey> change dir into /mnt/cdrom (or whatever)
andrey> right click, copy some file
andrey> change directory to somewhere on your disk
andrey> right click, paste
andrey> try to open tray

andrey> the result is hard to explain to a normal user because there is apparent no 
program accessing CD-ROM ... but konqueror does it behind your back :(

andrey> This is old problem. This _very_ old problem. One user on a.o.l.m described it 
as "my CD is snaping on me".

andrey> May I ask good fellas to check if it is still the case in current cooker and 
of not submit official bug report? What I never understood why could not konqueror use 
FAM for this ...

andrey> Alternative would be to disable autoclose for CD-ROMs (sysctl -w 
kernel.dev.cdrom.autoclose=0). May be this need to be set by default in sysctl.conf if 
nothing more is working? I guess having to manually close tray is less evil than what 
happens currently.

andrey> the problem is serious enough to spoil all impression even if supermount is 
otherweise working properly. fredl, it goes to you as owner of /etc/sysctl.conf :)

andrey> -andrey

I am very fast taking the cd out of the try :)

Seriosly, I can't see a good way (except changing konqueror) of doing
something sensible.  Process is:

- konqueror trys to access files
- supermount try to acces media.
- cdrom (not supermount) found that you try to use cdrom media, and
  the try is open, he thinks: stupid user, anyway I will close it for
  you.
- CDrom got fixed.

BTW, I just integrated all your patches in kernel for updates (will be
in next cooker kernel).  I just didn't delete put_inode() as your
patch does.  Now I am able to eject the cd in the middle of one
operation, insert again the cd, and the operation continues with only
some I/O Errors (as expected).

You cold get the kernel for updates in my web page later today
(offcial copy is still compiling):

http://people.mandrakesoft.com/~quintela/updates/9.0

Thansk for your patches.

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: nForce2 IDE support [patch included]

[Juan Quintela]

> "thomas" == Thomas Backlund <[EMAIL PROTECTED]> writes:

thomas> since the nforce2 ide wont work with latest cooker kernel:

thomas> kernel-2.4.21.0.pre3.1mdk-1-1mdk

thomas> I took Alan Cox ac4 patch and removed all but nforce2
thomas> patch and applied it to latest MDK kernel (above)...
thomas> (renamed it to: kernel-2.4.21.0.pre3.1TmB-1-1mdk)

thomas> It works great:
thomas> here is the hd speed with the MDK 9.0 kernel (on full Cooker):
thomas> /dev/hda:
thomas> Timing buffer-cache reads:   128 MB in  0.33 seconds =387.88 MB/sec
thomas> Timing buffered disk reads:  64 MB in 19.11 seconds =  3.35 MB/sec

thomas> and here is the speed with my patched kernel (on full Cooker):
thomas> /dev/hda:
thomas> Timing buffer-cache reads:   128 MB in  0.32 seconds =400.00 MB/sec
thomas> Timing buffered disk reads:  64 MB in  2.11 seconds = 30.33 MB/sec

thomas> So the patch is included with this mail.

thomas> And if you dont want to apply the patch yourself, go to:
thomas> http://www.iki.fi/~tmb/Cooker/

thomas> where you wil find:
thomas> - this patch
thomas> - precompiled 'up' kernel
thomas> - the kernel SRPM


Thanks, just included the whole diff with ac :p

Thanks, Juan.

Later, Juan.

thomas> To get the 3c920 nic on the nforce2 to work,
thomas> se my other mail..
thomas> -

thomas> Thomas
thomas> **
thomas> [EMAIL PROTECTED]  
thomas> www.iki.fi/~tmb/
thomas> **
thomas> * Theory is when you now everything, but nothing works...
thomas> * Reality is when everything works, but nobody nows why...
thomas> * Here Theory and Reality is combined...
thomas> * Nothing works, and Nobody nows why ...
thomas> *


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: PATCH: 2.4.20-2mdk: fix slow supermount on IDE devices

[Juan Quintela]

> "andrey" == Andrey Borzenkov <[EMAIL PROTECTED]> writes:

andrey> Danny, one more for your collection :) Should be the really last
andrey> problem known to me.

andrey> It fixes ridiculously slow read from IDE devices in some cases. The
andrey> reason was as usual very simple and is not supermount bug.

andrey> File read-ahead code never explicitly unplugs device queue after
andrey> submitting requests. Supermount checks for media change on every
andrey> operation (except read/write) and query_disk_change blocked until
andrey> queue was unplugged, i.e. tq_disk was run. This happened either
andrey> on next non-readahead IO request (not neccessarily for the same device,
andrey> it explains why supermount appeared to work normally during high
andrey> disk IO activity) or during next kupdated run that by default happens
andrey> every 5 seconds. This gives you those 4-5 second delays for every file.

andrey> The worst case was read-ahead of many files immediately followed by
andrey> close. In this case every close blocked for several seconds. And
andrey> this is exactly what happens when you run rpm - it scans all package
andrey> headers and waits several seconds between each file :)

andrey> The fix is to ensure that device IO is enabled before we are going
andrey> to sleep waiting for request. It should not break anything as far as
andrey> I can tell, SCSI layer does the same (so SCSI devices should not suffer
andrey> from this problem at all). Arguably this should happen in file read-ahead
andrey> code and comments there even suggest that it was intended but I do
andrey> not feel myself confident enough to touch the very heart of IO subsystem.

andrey> cheers

andrey> -andrey

integrated.


-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: PATCH: 2.4.20-2mdk: ide-proc && ide_scan cleanup

[Juan Quintela]

> "andrey" == Andrey Borzenkov <[EMAIL PROTECTED]> writes:

andrey> Again from very old backlog.
andrey> This fixes my old error. The patch is against 2.4.20-2mdk, but it reverts 
DI92, so Juan, if you intend to ever apply it :) just remove DI92 and skip 
drivers/ide/ide.c chunk.

andrey> The patch fixes driver changing by writing into /proc/ide/hdX/driver. It does 
work to some extent, but current code does not null-terminate written driver name so 
ide_scan_device does not (always) find it.

andrey> DI92 must be removed in any case (it is buggy); this patch is optional as 
probably nobody ever tried to play with IDE drivers this way :)) I repost it so it is 
not lost. 

andrey> -andrey

Patch applied.

DI92 will be removed in next one (just misread your mail :p)

Thanks, Juan.
-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

[Cooker] Re: PATCH: 2.4.20-2mdk: scsi_error timeout resubmitted

[Juan Quintela]

> "andrey" == Andrey Borzenkov <[EMAIL PROTECTED]> writes:

andrey> I have some old patches still lingering around.
andrey> - 2.4.19-q18.
andrey> ...
andrey> * scsi_error timeout patch

andrey> Juan, this is still unapplied (or have been lost during 2.4.19 -> 2.4.20 
move). I attach it against 2.4.20-2mdk.

andrey> Danny, I understand you maintain some unofficial kernel. You are adviced to 
add this one as well, current SCSI error handling too easily goes into endless loop on 
innocent media errors.

andrey> cheers

Also integrated in 2.4.21-pre3q1.

Thanks, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy