* Re: Are linux network drivers really affected by this?
From: andrea.glorioso @ 2003-01-10 11:12 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1042199207.28469.49.camel@irongate.swansea.linux.org.uk>
>>>>> "ac" == Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
ac> Most of them will pad with zero. We have a couple of drivers
ac> that already pad with something along the lines of "NetBSD is
ac> a cool OS too.."
Let's talk about subliminal messages, then. :)
How sensible would it be to have a runtime or compile time option for
choosing between zero padding and random values padding? I think the
variable length of the padding could cause some performance problems,
but I'm no kernel hacker nor cryptography expert.
ac> The -ac tree should have the problem fixed for all the drivers
ac> I know have the problem or may do.
Great.
bye,
andrea
--
Andrea Glorioso andrea.glorioso@binary-only.com
Binary Only http://www.binary-only.com/
Via A. Zanolini, 7/b Tel: +39-348.921.43.79
40126 Bologna Fax: +39-051-930.31.133
^ permalink raw reply
* netfilter scoreboard deactivated
From: Harald Welte @ 2003-01-10 11:02 UTC (permalink / raw)
To: Netfilter Development Mailinglist; +Cc: Netfilter Mailinglist
[-- Attachment #1: Type: text/plain, Size: 959 bytes --]
Hi!
The netfilter coreteam has decided to deactivate the scoreboard and
remove it until further notice.
The reason for this step is that the scoreboard has become out of date
since it was too much hazzle to maintain it manually. We think it's
unfair and discouraging for new contributors if the scoreboard shows
only old contributions.
There might be something similar to the scoreboard in the near future,
once our bugtracking system is up and running. The bugtracking system
could maintain the scores in an automatic fashion, without any manual
invervention needed.
Thanks for your understanding,
Harald (for the netfilter core team)
--
- Harald Welte / laforge@gnumonks.org http://www.gnumonks.org/
============================================================================
"If this were a dictatorship, it'd be a heck of a lot easier, just so long
as I'm the dictator." -- George W. Bush Dec 18, 2000
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
^ permalink raw reply
* Re: detecting hyperthreading in linux 2.4.19
From: Dave Jones @ 2003-01-10 11:05 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: jamesclv, Jason Lunz, linux-kernel
In-Reply-To: <15902.28835.127030.199073@harpo.it.uu.se>
On Fri, Jan 10, 2003 at 08:05:07AM +0100, Mikael Pettersson wrote:
> If the kernel has sched_setaffinity() or some other way of binding a process
> to a given CPU (as numbered by the kernel, which may or may not be related
> to any physical CPU numbers), then this will do it: execute CPUID on each
> CPU and check the initial APIC ID field. If you find one that's non-zero,
> then HT is enabled.
That's a horrible way of reimplementing /dev/cpu/x/cpuid 8-)
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* DSDT for Compaq Presario 1720US
From: Prabhakar Reddy Gudla Venkata Siva @ 2003-01-10 10:59 UTC (permalink / raw)
To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20030110103707.GA12313-XEk0yrNnxERrk9EDFsdIuomMxnTEL9wi0E9HWUfgJXw@public.gmane.org>
Hi list,
I am trying to resume my efforts to get ACPI support for my Compaq
Presario 1720US. I was able to use ACPI patch from Dec' 01 and the
two subsequent patches released after Dec '01 (yes it is Dec '01). But
since April '02 patches I was never able to even get ACPI support due to
either of the following:
1) Boot-up problems
2) DSDT problems (related to 1)
3) IRQ problems (on corrected DSDT)
Well, I stopped pursuing the ACPI support since Aug '02. Thought someone
else would get it working on same make as mine and would follow his/her
footsteps.
So, I was wondering if anyone on the list has ever had success with recent
ACPI patches on Compaq Presario 1720US (or it's close brethren) ? By
success I mean, clean compile, battery status, etc.
I have seen people expressing sucess with Compaq Evo, Presario 27xx series
but unfortuantely the specs, hence the DSDT are different. I am willing to
post my DSDT, again, if that helps.
regards
*******************************--------------**********************************
Prabhakar Reddy Gudla
Research Assistant
Model Analysis Lab
Biological Resources Engineering
University of Maryland
College Park, MD, 20742.
tel: 301-405-0109 (o)
fax: 301-314-9023
email: reddyg-e45ueOrobK4@public.gmane.org
**************************--------------------*********************************
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: [TRIVIAL] [PATCH 1 of 3] Fix errors making Docbook documentation
From: Alan Cox @ 2003-01-10 11:53 UTC (permalink / raw)
To: Rusty Russell; +Cc: Linus Torvalds, Linux Kernel Mailing List, Craig Wilkie
In-Reply-To: <20030110073328.A11712C0DD@lists.samba.org>
On Fri, 2003-01-10 at 00:50, Rusty Russell wrote:
> > Please don't do this. The proper fixes already exist just never got
> > merged. Also documentation exists for those files and isnt merged. The
> > docbook is not the problem, the pile of other missing bits is
> >
> > Grab the docbook for those files from 2.4 and also the changes to the
> > docbook generator
>
> Too late, Linus took it. Craig, since you're doing Documentation
> patches, a forward port would be nice.
I thought bitkeeper had an "exclude" function ?
Alan
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Benjamin Herrenschmidt @ 2003-01-10 11:07 UTC (permalink / raw)
To: Alan Cox
Cc: fverscheure, Linux Kernel Mailing List, Marcelo Tosatti,
Andre Hedrick
In-Reply-To: <1042198670.28469.45.camel@irongate.swansea.linux.org.uk>
On Fri, 2003-01-10 at 12:37, Alan Cox wrote:
> > And by the way how are powered off the IDE drives ?
> > Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before powering off the
> > drive with cache enabled or you will enjoy lost data
>
> IDE disagrees with itself over this but when we get a controlled power
> off we do this. The same ATA5/ATA6 problem may well be present there
> too. I will review both
I did fix a data loss problem with some PPC laptops that way too, that
is just before shutdown and just before machine sleep, sending a STANDBYNOW
command. In the case of machine sleep, I make sure not to accept any more
request (mark the hwif busy) after that and until machine wake up (at which
point I do a full hard reset or poweron reset of the drive).
Ben.
^ permalink raw reply
* Re: Are linux network drivers really affected by this?
From: Alan Cox @ 2003-01-10 11:46 UTC (permalink / raw)
To: andrea.glorioso; +Cc: Linux Kernel Mailing List
In-Reply-To: <87iswx4eaw.fsf@topo.binary-only.priv>
On Fri, 2003-01-10 at 08:08, andrea.glorioso@binary-only.com wrote:
> The paper presented by Olaf Arkin (amongst other) points to some parts
> of the linux code where this "vulnerability" exists. I think Alan Cox
> is working on some patches for his tree. I wonder whether it's better
> to null-pad ethernet packets or to fill them with random values
> (possibly an overkill, but more resiliant against fingerprinting).
Most of them will pad with zero. We have a couple of drivers that already
pad with something along the lines of "NetBSD is a cool OS too.."
The -ac tree should have the problem fixed for all the drivers I know have
the problem or may do.
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: jsoe0708 @ 2003-01-10 10:51 UTC (permalink / raw)
To: Randolph Chung; +Cc: parisc-linux
In-Reply-To: <20030110073659.GC31470@tausq.org>
>-- Original Message --
>Date: Thu, 9 Jan 2003 23:36:59 -0800
>From: Randolph Chung <randolph@tausq.org>
>To: jsoe0708@tiscali.be
>Cc: parisc-linux@lists.parisc-linux.org
>Subject: Re: [parisc-linux] unaligned accesses
>Reply-To: Randolph Chung <randolph@tausq.org>
>
>
...
>
>> hmmm buggy: not always, the triky case is when you have to access to
those
>> kind of data encapsulated into a structure. I do not yet find any work=
around
>> or how to fix this kind of pb. Any idea (gcc-3.3?)?
>
>eh? what do you mean?
Sorry, I met well a problem of unaligne access problem with fsck.jfs (wit=
h
kernel 2.4.19-pa24+jfs 1.0.23 support):
...
fsck.jfs(6995): unaligned access to 0xfaf00757 at ip=3D0x0002ee1b
fsck.jfs(6995): unaligned access to 0xfaf00757 at ip=3D0x0002ee37
fsck.jfs(6995): unaligned access to 0xfaf00757 at ip=3D0x0002ed3f
...
which occurs in fsckmsgs.c for ip=3D0x0002ee1b (for exapmple) at:
strncpy(prlimit, msgprms[prmidx], prmval[prmidx]);
with
...
extern char *msgprms[];
...
int prmidx;
...
int16_t *prmval;
So it is not related with the struct problem I encounter.
I will try to find back this example.
Joel
PS: with ext3 (which I use) problem I hesitate to install 2.4.20 and wai=
ting
for 2.4.21 and evms, jfs, xfs support for this system)
********************************************
Promo Tiscali ADSL: 35 Euros/mois, 1er mois et activation =3D 0 Euro http=
://adsl.tiscali.be
^ permalink raw reply
* Re: Problem: kernel BUG at page_alloc.c:217!
From: Alan Cox @ 2003-01-10 11:45 UTC (permalink / raw)
To: t.widjaja1; +Cc: Linux Kernel Mailing List
In-Reply-To: <200301100825.TAA17664@cassius.its.unimelb.edu.au>
Remove the Nvidia driver, boot from scratch and duplicate the problem, otherwise since Nvidia
have our source and we don't have theirs only they can help you
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Horst von Brand @ 2003-01-10 10:55 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
In-Reply-To: <20030109222748.GA3993@gtf.org>
Jeff Garzik <jgarzik@pobox.com> said:
> Anybody know where the source rpm for UnitedLinux kernel is?
> [to be distinguished from kernel-source rpm]
>
> AFAICS they are not distributing source code to their published kernel
> binaries... which is a very obvious GPL violation.
If the binary can be recreated from the source in the kernel-source RPM,
they aren't in violation. Sure, having a look at the non-official patches
they apply would be nice, but not mandated by GPL.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: clipping
From: Geert Uytterhoeven @ 2003-01-10 10:45 UTC (permalink / raw)
To: Antonino Daplas; +Cc: James Simmons, Linux Frame Buffer Device Development
In-Reply-To: <1042172016.933.136.camel@localhost.localdomain>
On 10 Jan 2003, Antonino Daplas wrote:
> On Fri, 2003-01-10 at 05:24, James Simmons wrote:
> > > So perhaps, a function something like this:
> > >
> > > void fb_clip(struct fb_fillrect *region, struct fb_fillrect *clip);
> > >
> > > This should not be difficult to implement, and I'll code it if everyone
> > > agrees.
> >
> > I thought about this. Originally I did have this function but removed it.
> > WHat do you think Geert?
> >
> > > The other option (which I don't like) is just to check the passed
> > > fb_var_screeninfo in the put_var ioctl against the current console
> > > window size. But this is not foolproof as we will not be sure of the
> > > resulting window size _after_ the fb_set_var() call.
> >
> > Yuck!!! The other way is better.
> >
>
> Yes, I thought so too :-).
>
> I think one scenario why we need clipping is changing bits_per_pixel,
> ie, changing from 8->16 will drop your vyres by half and it's difficult
> to determine this unless you do another check before the set_par(), as
> Geert mentioned. Worse still, there is little if no valid memory past
> vyres but the console thinks there is. That's where you will get a
> segfault.
>
> Whereas explicitly doing fbset -vyres 768 will not cause a segfault,
> because you still have valid framebuffer memory past y=768.
That depends. On unified memory architectures or if the graphics memory is
shared by two heads, you may still corrupt someone's memory.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Problem in IDE Disks cache handling in kernel 2.4.XX
From: Alan Cox @ 2003-01-10 11:37 UTC (permalink / raw)
To: fverscheure; +Cc: Linux Kernel Mailing List, Marcelo Tosatti, Andre Hedrick
In-Reply-To: <20030110095558.E144CFF11@postfix4-1.free.fr>
On Fri, 2003-01-10 at 09:54, Francis Verscheure wrote:
> In fact for ATA/ATAPI 5 cfs_enable_2 has no meaning. The fields to test are
> write cache bits in command_set_1 and cfs_enable_1.
> And in both cases the FLUSH CACHE command ALWAYS EXISTS !
> The test of cfs_enable_2 must only be used for ATA/ATAPI 6 drives to use
> FLUSH CACHE or FLUSH CACHE EXT in case of 48 bit addressing mode.
Thanks for the report. I need to go reread the spec before I can
definitively comemnt on this.
> And it seems to me that when an IDE drive has a cache enabled wcache must be
> initialized to say so ? Or you have to do a STANDY or SLEEP before APM
> suspend or power off to be sure that the cache has been written to the disk.
Technically - no. In the real world its a very very good idea
> I had a look at patch 2.4.21pre3 and the code looks the same.
>
> And by the way how are powered off the IDE drives ?
> Because a FLUSH CACHE or STANDY or SLEEP is MANDATORY before powering off the
> drive with cache enabled or you will enjoy lost data
IDE disagrees with itself over this but when we get a controlled power
off we do this. The same ATA5/ATA6 problem may well be present there
too. I will review both
Any specific opinion Andre ?
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Henning P. Schmiedehausen @ 2003-01-10 10:51 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <E18WlrH-0000NO-00@fencepost.gnu.org>
Richard Stallman <rms@gnu.org> writes:
>There is no such thing as an open source community. The people who
>founded the open source movement in 1998, and the people who support
>it now, are part of the free software community. (We in the free
Open Source != Free Software. Else Microsoft would be part of the
"free software community", because they open up their sources, too.
There is "free software (free as in free beer)" which is not open
sourced.
As you build most of your assumptions on this, this is where you whole
logic breaks down.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: Kernel Oops with HIMEM+VM in 2.4.19,20
From: William Lee Irwin III @ 2003-01-10 10:48 UTC (permalink / raw)
To: Anthony Lau; +Cc: linux-kernel
In-Reply-To: <20030110083714.GA702@kimagure>
On Fri, Jan 10, 2003 at 12:37:14AM -0800, Anthony Lau wrote:
> I am getting reproducible kernel oops and random segmentation
> faults whenever the kernel starts using VM. Without any VM pages
> being used, the system is stable.
> I have tested kernels compiled with and without HIMEM support
> (all other kernel config options identical). Without HIMEM 4GB
> support, the system is stable for weeks. With HIMEM 4GB support,
> the system starts oops'ing and seg. faulting when VM starts
> being used.
> My system info:
> 1.5GB physical RAM (MemTest86 run for 2 times, no errors)
> 2.0GB VM on a partition
> Aopen AX34u with Via Apollo Pro 133T chipset
Hmm, I'd call the "VM on a partition" something like "swap" myself.
This looks tiny, it's almost certainly not one of the "spin forever
hunting for a lowmem page intermixed with all the highmem pages" like
the big ones get burned by all the time on 2.4.x.
On Fri, Jan 10, 2003 at 12:37:14AM -0800, Anthony Lau wrote:
> Sample Oops from logs:
> Jan 8 08:53:59 kimagure kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000317
> Jan 8 08:53:59 kimagure kernel: printing eip:
> Jan 8 08:53:59 kimagure kernel: c0146053
> Jan 8 08:53:59 kimagure kernel: *pde = 00000000
> Jan 8 08:53:59 kimagure kernel: Oops: 0000
> Jan 8 08:53:59 kimagure kernel: CPU: 0
> Jan 8 08:53:59 kimagure kernel: EIP: 0010:[free_kiovec+83/108] Not tainted
> Jan 8 08:53:59 kimagure kernel: EFLAGS: 00010202
> Jan 8 08:53:59 kimagure kernel: eax: 00000000 ebx: df7dcc34 ecx: df7dcc44 edx: df7dcc44
> Jan 8 08:53:59 kimagure kernel: esi: f6784800 edi: 00000307 ebp: 00000c59 esp: c222df4c
> Jan 8 08:53:59 kimagure kernel: ds: 0018 es: 0018 ss: 0018
> Jan 8 08:53:59 kimagure kernel: Process kswapd (pid: 5, stackpage=c222d000)
> Jan 8 08:53:59 kimagure kernel: Stack: de765b48 de765b30 df7dcc34 c0144226 df7dcc34 00000011 000001d0 00000020
> Jan 8 08:53:59 kimagure kernel: 00000006 c01444eb 000056a6 c012d760 00000006 000001d0 00000006 000001d0
> Jan 8 08:53:59 kimagure kernel: c03180c8 00000000 c03180c8 c012d7af 00000020 c03180c8 00000002 c222c000
> Jan 8 08:53:59 kimagure kernel: Call Trace: [destroy_inode+22/44] [sync_inodes_sb+159/468] [rw_swap_page_base+32/296]
> [rw_swap_p
> age_base+111/296] [rw_swap_page_base+259/296]
> Jan 8 08:53:59 kimagure kernel: [rw_swap_page+54/72] [__free_pages_ok+109/612] [kernel_thread+40/56]
> Jan 8 08:53:59 kimagure kernel:
> Jan 8 08:53:59 kimagure kernel: Code: 8b 47 10 85 c0 74 06 53 ff d0 83 c4 04 ff 4b 2c 0f 94 c0 84
Looks like someone e.g. invalidate_inode_pages(), truncate_inode_pages(),
etc. etc., left pages hanging around. Borderline VM/vfs stuff. Or swap
code mangled something important. This oops either has buttloads of
stack noise or some other issue corrupting it. Can you find the first
oops? If this is not the first oops, then it's probably not useful.
On Fri, Jan 10, 2003 at 12:37:14AM -0800, Anthony Lau wrote:
> Because of the symptoms, I think that there could be some
> incompatibility between Himem and the VM subsystem. Of course
> I may have just configured my kernel incorrectly.
> Any help is appreciated and I will gladly supply more logs
> if I knew which ones would be useful.
No, it looks like VM/vfs interation-related stuff.
Bill
^ permalink raw reply
* Re: const fb_{fillrect,copyarea,image}?
From: Antonino Daplas @ 2003-01-10 10:28 UTC (permalink / raw)
To: James Simmons; +Cc: Geert Uytterhoeven, Linux Frame Buffer Device Development
In-Reply-To: <Pine.LNX.4.44.0301091814550.5660-100000@phoenix.infradead.org>
On Fri, 2003-01-10 at 02:16, James Simmons wrote:
>
> > BTW, is it possible that someone passes data that is larger (except for bugs)?
> > We have control over what happens in the kernel. Data passed from userspace is
> > a different issue, of course.
>
> Yes. Soon the standard ioctl for a cursor will be truly in place. This
> means cfb_imageblit could be a issue from userland.
>
If you are going to export the cursor API to userland, then soft_cursor
is useless, because it implies that we always have a copy of the screen
under the cursor (so we can restore it when we move the cursor) and it
also implies that fb_imageblit can support transparency (so the mask
bits will work). For soft cursors, the userland has to take care of it.
For those with hardware cursors, this is exportable to user space.
The structure fbcursor has one field that is console specific
fbcursor.dest which we basically use to invert the cursor image. So the
structure that is passed via the cursor ioctl will be slightly
different, it should not have the 'dest' field. So when it gets passed
to fb_cursor(), dest == NULL. Then this is how drivers can respond:
1. soft_cursor - if cursor->dest == NULL, always exit with an error.
2. hardware cursors which cannot do invert - if cursor->dest == NULL and
rop == ROP_XOR, exit with an error, otherwise (ROP_COPY), proceed.
3. hardware cursors with invert - cursor->dest will be ignored so it has
full support.
The rivafb_cursor() and i810fb_cursor() already behaves like #2 already.
Anyway, inverting the cursor image is not commonly used in GUI apps.
Typically, they just need an opaque cursor + a transparency mask to
"shape" the cursor.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: clipping
From: Antonino Daplas @ 2003-01-10 10:27 UTC (permalink / raw)
To: James Simmons; +Cc: Geert Uytterhoeven, Linux Frame Buffer Device Development
In-Reply-To: <Pine.LNX.4.44.0301092122450.5660-100000@phoenix.infradead.org>
On Fri, 2003-01-10 at 05:24, James Simmons wrote:
>
> > So perhaps, a function something like this:
> >
> > void fb_clip(struct fb_fillrect *region, struct fb_fillrect *clip);
> >
> > This should not be difficult to implement, and I'll code it if everyone
> > agrees.
>
> I thought about this. Originally I did have this function but removed it.
> WHat do you think Geert?
>
> > The other option (which I don't like) is just to check the passed
> > fb_var_screeninfo in the put_var ioctl against the current console
> > window size. But this is not foolproof as we will not be sure of the
> > resulting window size _after_ the fb_set_var() call.
>
> Yuck!!! The other way is better.
>
Yes, I thought so too :-).
I think one scenario why we need clipping is changing bits_per_pixel,
ie, changing from 8->16 will drop your vyres by half and it's difficult
to determine this unless you do another check before the set_par(), as
Geert mentioned. Worse still, there is little if no valid memory past
vyres but the console thinks there is. That's where you will get a
segfault.
Whereas explicitly doing fbset -vyres 768 will not cause a segfault,
because you still have valid framebuffer memory past y=768.
Tony
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: UnitedLinux violating GPL?
From: Henning P. Schmiedehausen @ 2003-01-10 10:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20030110083409.GH30114@suse.de>
Hubert Mantel <mantel@suse.de> writes:
>ftp.suse.com:/pub/unitedlinux/1.0/src/kernel-source-2.4.19.SuSE-82.nosrc.rpm
^^^^^^^^^^^^^^^ ^^^^^^^
Revealing...
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: ACPI problems on Athlon MP system
From: Arndt Schoenewald @ 2003-01-10 10:37 UTC (permalink / raw)
To: Martin Siegert; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20030110030741.GA2580-0ze2hujOWYhqr3d4nwidZ7Dks+cytr/Z@public.gmane.org>
Hi Martin,
the ACPI support in the 2.4 kernel series is very old (from autumn
2001 if I remember correctly), so you should use the ACPI patch from
http://sourceforge.net/projects/acpi; in your case
http://prdownloads.sf.net/acpi/acpi-20021212-2.4.20.diff.gz
(This patch applies cleanly against linux-2.4.21-pre2 from kernel.org
even though it was done for 2.4.20.)
The Intel people are trying to get an updated ACPI version into 2.4,
but I guess this will not happen before 2.4.22. The 2.5 kernel series
does already include a current ACPI version.
Good luck,
Arndt
On Thu, Jan 09, 2003 at 07:07:41PM -0800, Martin Siegert wrote:
> Hi,
>
> I am not sure whether this is the correct place to ask this question,
> but hopefully you can point me in the right direction.
>
> Here is the problem:
> I am trying to get the "poweroff" command working on an Athlon MP
> (Tyan S2462) system (linux-2.4.21-pre2; otherwise RedHat 7.3).
>
> The machine has ACPI enabled in the bios. When I compile the kernel
> with ACPI disabled, the poweroff command shuts down the system, but
> does not shut off the power (it acts exactly like the halt command).
> In order to shutoff the machine I must press the power switch.
>
> When I compile the kernel with ACPI enabled the situation is worse:
> the halt and poweroff commands still work in exactly the same way
> (shutdown the system), but now I cannot switch off the machine
> anymore: pressing the power switch has absolutely no effect
> (regardless of how long I hold the switch). The only way to
> switch off the machine is to either pull the power cord or to
> press the reset button on then the power switch (which will then
> switch off the machine when it reboots).
>
> What am I doing wrong? Am I missing some kernel switches, options?
> Do I need additional software?
>
> Any help or suggestions, hints are appreciated!
>
> Thanks in advance,
>
> Martin
--
Arndt Schoenewald <abs-SA7OhAOe25xnNxvc45mVi0K323yFvGpRdefyYXQ/eNw@public.gmane.org>, Software Developer
Quelltext AG (http://www.quelltext-ag.de), Dortmund, Germany
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Reg iptables Connection tracking
From: Amit Kumar Gupta @ 2003-01-10 10:34 UTC (permalink / raw)
To: netfilter
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
On Friday 10 January 2003 12:37 am, you wrote:
> Hi,
>
> Well, Only 2 machines are attached in the inhome network and the
> fireall I am using is written using iptables rule. Well, the
> interesting point is :- There is no
> /proc/sys/net/ipv4/ip_conntrack_max file . What I mean is the max
> length it takes from this file and this file doesn't exist as I am not
> using /proc file system. (This mean that in the kernel CONFIG_SYSCTL
> option is not set).
>
> Well I am able to see upto this point. I went through the code flow
> also. But I don't know why it prints the message(Even if increasing
> the value from 1016 to 4096 by hardcoding it in the kernel). Another
> issue is I don't know how it is taking 1016. As There is no /proc file
> system, and by default it shoud take 0.
Hmmm. I suspect it is taking a 1024 default then, the actual number of
entries usually seems to be (2^n)-8. The following probably explains
/where/ the value is coming from:
int __init ip_conntrack_init(void)
{
unsigned int i;
int ret;
/* Idea from tcp.c: use 1/16384 of memory. On i386: 32MB
* machine has 256 buckets. >= 1GB machines have 8192 buckets.
*/
if (hashsize) {
ip_conntrack_htable_size = hashsize;
} else {
ip_conntrack_htable_size
= (((num_physpages << PAGE_SHIFT) / 16384)
/ sizeof(struct list_head));
Not that this helps much. The real problem is WHAT is the conntrack
table filling with. And I suspect it may be nothing, that you have a
problem because it is trying to use /proc/net/conntrack and there IS no
/proc/net/conntrack. The message may be triggering incorrectly,
presuming that since it cannot write another entry to
/proc/net/conntrack that the table is full.
The fact that you only have two machines pretty much eliminates traffic
as a source of legitimately filling it... :^)
I'm out of ideas for the moment, other than the above, that it will need
/proc in order to work. If I think of something else I'll email you
again. Sorry.
j
[-- Attachment #2: Wipro_Disclaimer.txt --]
[-- Type: text/plain, Size: 514 bytes --]
**************************Disclaimer************************************************
Information contained in this E-MAIL being proprietary to Wipro Limited is
'privileged' and 'confidential' and intended for use only by the individual
or entity to which it is addressed. You are notified that any use, copying
or dissemination of the information contained in the E-MAIL in any manner
whatsoever is strictly prohibited.
***************************************************************************************
^ permalink raw reply
* Re: [PATCH] USB MIDI: fix endpoint detection
From: Takashi Iwai @ 2003-01-10 10:33 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: alsa-devel
In-Reply-To: <Pine.HPX.4.33n.0301100859410.22560-100000@studcom.urz.uni-halle.de>
At Fri, 10 Jan 2003 09:08:47 +0100 (MET),
Clemens Ladisch wrote:
>
>
> This patch removes the implicit assumption that devices with
> QUIRK_MIDI_FIXED_ENDPOINT use the same endpoint number for input and
> output pipes. (This broke with the Edirol PCR-30/50.)
thanks, now committed to cvs.
the patch was rejected by some reason (whitespace?), so i did apply
manually. please check whether it's ok for you.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: ACPI problems on Athlon MP system
From: Pavel Machek @ 2003-01-10 10:31 UTC (permalink / raw)
To: Martin Siegert; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20030110030741.GA2580-0ze2hujOWYhqr3d4nwidZ7Dks+cytr/Z@public.gmane.org>
Hi!
> I am not sure whether this is the correct place to ask this question,
> but hopefully you can point me in the right direction.
>
> Here is the problem:
> I am trying to get the "poweroff" command working on an Athlon MP
> (Tyan S2462) system (linux-2.4.21-pre2; otherwise RedHat 7.3).
>
> The machine has ACPI enabled in the bios. When I compile the kernel
> with ACPI disabled, the poweroff command shuts down the system, but
> does not shut off the power (it acts exactly like the halt command).
> In order to shutoff the machine I must press the power switch.
>
> When I compile the kernel with ACPI enabled the situation is worse:
> the halt and poweroff commands still work in exactly the same way
> (shutdown the system), but now I cannot switch off the machine
> anymore: pressing the power switch has absolutely no effect
> (regardless of how long I hold the switch). The only way to
> switch off the machine is to either pull the power cord or to
> press the reset button on then the power switch (which will then
> switch off the machine when it reboots).
Try holding power switch for 5 seconds, that should switch it off.
> What am I doing wrong? Am I missing some kernel switches, options?
> Do I need additional software?
try echo 5 > /proc/acpi/sleep. If it powers down, what you see is
userland bug.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
^ permalink raw reply
* Re: [PATCH] Make `obsolete params' work correctly if MODULE_SYMBOL_PREFIX is non-empty
From: Miles Bader @ 2003-01-10 10:39 UTC (permalink / raw)
To: Rusty Russell; +Cc: linux-kernel, torvalds
In-Reply-To: <20030110073328.D41A52C310@lists.samba.org>
BTW, I noticed that there's actually a bug in my patch -- it assumes
the length of MODULE_SYMBOL_PREFIX is 1. So change:
char sym_name[strlen(obsparm[i].name) + 2];
to:
char sym_name[strlen(obsparm[i].name) + sizeof MODULE_SYMBOL_PREFIX];
-Miles
--
Would you like fries with that?
^ permalink raw reply
* (no subject)
From: Adam.Szabo @ 2003-01-10 10:29 UTC (permalink / raw)
To: nfs
hi im using a SuSE Linux distribution (newest firewall CD 2)
i want to install NFS, but i cannot find mountd - where can i get the
nfs-utils ??
thx
adam
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
^ permalink raw reply
* Re: DMA timeouts on Promise 20267 IDE card
From: James Curbo @ 2003-01-10 10:33 UTC (permalink / raw)
To: Manish Lachwani; +Cc: linux-kernel
In-Reply-To: <233C89823A37714D95B1A891DE3BCE5202AB1B7A@xch-a.win.zambeel.com>
On Jan 09, Manish Lachwani wrote:
> You should change the drive hda and also the cable. Then try again.
>
Oops! One of my IDE cables wasn't seated properly. Thanks for the help!
At least it wasn't a kernel bug :)
--
James Curbo <hannibal@adtrw.org> <phoenix@sandwich.net>
http://www.adtrw.org/blogs/hannibal/
^ permalink raw reply
* Re: "Mother" == "computer-illiterate"
From: Henning P. Schmiedehausen @ 2003-01-10 10:35 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1042153890.28469.21.camel@irongate.swansea.linux.org.uk>
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
>On Thu, 2003-01-09 at 19:40, Val Henson wrote:
>> P.S. For extra credit (but no ThinkGeek certificate) you can look up
>> the following women in computer science, some of whom are mothers:
>> Mary Baker, Margo Seltzer, Monica Lam, Ellen Spertus, Carla Ellis, and
>> Barbara Simons.
>and of course Sally Floyd, and even Hedy Lamarr (bonus points for those
>who know what her networking related patent is on)
Come on, she actually has a homepage: http://www.hedylamarr.at/
-> frequency hopping
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.