* Re: Sound-related hard-locking
From: Stas Sergeev @ 2002-12-12 17:56 UTC (permalink / raw)
To: linux-msdos
Hello.
J. Solomon Kostelnik wrote:
> But last night the same thing happened when I was playing an
> MP3 with XMMS and then booted XDOS (without midid running).
> As soon as the XDOS window opened, my machine hard-locked.
Hmm, doesn't look dosemu-related at a
first glance.
> vanilla 2.4.18 kernel
This may be a problem. Try 2.4.20 as
all the older kernels were easy to
lock up by dosemu, which is now fixed.
> Maestro 2E.
And what about video? It was reported
that xdos crashes X sometimes on some
video boards. Try running console
dosemu and see if the problem is still
there (apply the post-less video patch
at first).
> Is there a way I can log this before it crashes and get any meaningful
> data before it happens?
Try ALSA drivers with OSS emulation.
Maybe it is just an ESS OSS driver buggy
and the current dosemu sound code is
extremely evil to the underlaying drivers
and exposes all of their hidden bugs.
It locks up the Aureal drivers on my
machine after some minutes of playing,
but as that drivers are proprietary, this
can't be fixed.
Another usefull test would be to try
dosemu with a pc-speaker OSS driver. If
the problem goes away by this, then it
is definitely a problem of your OSS driver.
Because even if the dosemu sound code
is buggy, this doesn't excuse a kernel
lock-ups.
^ permalink raw reply
* PROCESS IMIGRATION
From: Breno @ 2002-12-12 18:04 UTC (permalink / raw)
To: Kernel List
Hi
I saw something about one project of FreeBSD and this is about imigration of
processes between two machines.
The kernel Linux has something about this , or some project like that ?
thanks
Breno
^ permalink raw reply
* 2.4.20-ac1 KT400 AGP support
From: BoehmeSilvio @ 2002-12-12 18:04 UTC (permalink / raw)
To: linux-kernel
Hi !
Hopefully I'm right here.....
I have some trouble to get agpgart working in kernel 2.4.20-ac1.
My setup:
- ASUS A7V8X with VIA KT400 Chip (AGP 8X)
- ATI Radeon 9700 PRO (also AGP 8X)
The original 2.4.20 kernel doesn't know this chipset, so I tried the
2.4.20-ac1, which has some patches for the KT400.
With 2.4.20-ac1 I get the following error:
agpgart: Maximum main memory to use for agp memory: 690M
agpgart: Detected Via Apollo KT-400 chipset
agpgart: unable to determine aperture size
By
Silvio
^ permalink raw reply
* Re: [resend] mixer controls for bass/treble in emu10k driver
From: Takashi Iwai @ 2002-12-12 17:51 UTC (permalink / raw)
To: jordan.breeding; +Cc: alsa-devel
In-Reply-To: <E18MXOV-0000Lq-00@sc8-sf-list1.sourceforge.net>
At Thu, 12 Dec 2002 17:45:00 +0000,
jordan.breeding@attbi.com wrote:
>
> Is it possible for the emu10k (SBLive!/Audigy) driver to get bass/treble
> mixer controls in ALSA like it has in Windows and the OSS Linux (when you load
> the right file with the emu10k tools) driver? Thanks.
yes. you need to turn on "Tone Control" switch, then bass and treble
volumes will respond.
ciao,
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [PATCH-2.5.50-ac1] Compaq Triflex IDE driver
From: Alan Cox @ 2002-12-12 18:35 UTC (permalink / raw)
To: Torben Mathiasen; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021212153004.GC1378@tmathiasen>
On Thu, 2002-12-12 at 15:30, Torben Mathiasen wrote:
> Hi,
>
> Attached is a chipset driver for the Compaq Triflex IDE device
> (PCI device ID 0xae33). Enables Busmaster DMA on both devices.
>
> Known to work with the Compaq Workstation 5x00 series.
>
> Let me know of any problems.
I'll give it a spin, excellent stuff
^ permalink raw reply
* Re: [PATCH] Notifier for significant events on i386
From: John Levon @ 2002-12-12 17:58 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: vamsi, Alan Cox, Linux Kernel Mailing List
In-Reply-To: <1039715615.1649.80.camel@dell_ss3.pdx.osdl.net>
On Thu, Dec 12, 2002 at 09:53:35AM -0800, Stephen Hemminger wrote:
> The use of notifier today is limited to things that can't sleep. As far
kernel/profile.c
You'd have to move that to a different API if you want to force notifier
callbacks non-sleepable
regards
john
--
"Anyone who says you can have a lot of widely dispersed people hack away on
a complicated piece of code and avoid total anarchy has never managed a
software project."
- Andy Tanenbaum
^ permalink raw reply
* rmap15a swappy?
From: Sean Neakums @ 2002-12-12 17:46 UTC (permalink / raw)
To: linux-mm
I just fitted an extra 512M of RAM to my laptop, and though there is
currently about 400M free, it is still hitting swap. I seem to recall
that older rmaps generally only started to page stuff out when there
was no more memory free. (My recollection may be faulty, though.)
Some random info:
[revox(~)] uname -a
Linux revox 2.4.20-rmap15a-4 #1 Mon Dec 9 12:47:13 GMT 2002 i686 unknown unknown GNU/Linux
[revox(~)] cat /proc/meminfo
total: used: free: shared: buffers: cached:
Mem: 792940544 288563200 504377344 0 3063808 184758272
Swap: 539852800 34787328 505065472
MemTotal: 774356 kB
MemFree: 492556 kB
MemShared: 0 kB
Buffers: 2992 kB
Cached: 146456 kB
SwapCached: 33972 kB
Active: 110840 kB
ActiveAnon: 78764 kB
ActiveCache: 32076 kB
Inact_dirty: 0 kB
Inact_laundry: 139960 kB
Inact_clean: 7644 kB
Inact_target: 51688 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 774356 kB
LowFree: 492556 kB
SwapTotal: 527200 kB
SwapFree: 493228 kB
[revox(~)] uptime
17:42:26 up 41 min, 6 users, load average: 0.00, 0.02, 0.03
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <sneakums@zork.net> | answers a prison for oneself.
\ |
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: [PATCH] Notifier for significant events on i386
From: Stephen Hemminger @ 2002-12-12 17:53 UTC (permalink / raw)
To: vamsi; +Cc: Alan Cox, John Levon, Linux Kernel Mailing List
In-Reply-To: <20021212130406.A20253@in.ibm.com>
On Wed, 2002-12-11 at 23:34, Vamsi Krishna S . wrote:
> On Thu, Dec 12, 2002 at 12:25:47AM +0000, Stephen Hemminger wrote:
> >
> > This patch changes notifier to use RCU. No interface change, just a little
> > more memory in each notifier_block. Also some formatting cleanup.
> > Please review and give comments.
> >
> > <snip patch>
>
> This looks good. I have a few of comments:
>
> - add read_lock_rcu() / read_unlock_rcu() around the loop in
> notifier_call_chain() to be preempt-safe.
>
> - I would suggest using struct list_head in the notifier_block
> and use the RCU list routines from include/linux/list.h
> instead of spreading subtle RCU memory-barrier black magic.
That would be good for a new interface, but the existing code depends on
the single linked behavior. Many initializer's are pre-C99 style, and
more importantly there is no distinction between a list element and a
list head. To work with list macros the head has to be initialized
correctly. It is better not to worry about changing the interface and
avoid having to change all the calling code.
The only advantage to the doubly-linked list (besides std macros) is
that it is possible to unregister without knowing the head. There was a
patch several months ago to do singly-linked list macros but it looks
like it never got accepted. If the obscurity of the macro's is desired
then maybe the way to go is creating a slist.h with RCU extensions.
> - Even though RCU list reading is lockless, premption needs to
> be disabled while reading as mentioned above. So, we do
> need an __notifier_call_chain() version for those handlers
> that could sleep inside the handler: they will have to
> handle the required locking themselves.
The use of notifier today is limited to things that can't sleep. As far
as I can tell, it is intended for system events like reboot, panic;
where sleeping doesn't make sense. I think that is why the original
notifier_call_chain did not grab the read_lock.
--
Stephen Hemminger <shemminger@osdl.org>
Open Source Devlopment Lab
^ permalink raw reply
* [resend] mixer controls for bass/treble in emu10k driver
From: jordan.breeding @ 2002-12-12 17:45 UTC (permalink / raw)
To: alsa-devel
Is it possible for the emu10k (SBLive!/Audigy) driver to get bass/treble
mixer controls in ALSA like it has in Windows and the OSS Linux (when you load
the right file with the emu10k tools) driver? Thanks.
Jordan
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Re: [PATCH] 2.5.51 SCSI_IOCTL_GET_IDLUN + _GET_BUS_NUMBER
From: Jens Axboe @ 2002-12-12 17:42 UTC (permalink / raw)
To: James Bottomley; +Cc: dougg, linux-scsi
In-Reply-To: <200212121427.gBCERG502453@localhost.localdomain>
On Thu, Dec 12 2002, James Bottomley wrote:
> dougg@torque.net said:
> > For disks both the SCSI_IOCTL_GET_IDLUN and SCSI_IOCTL_GET_BUS_NUMBER
> > ioctls return the value 0 (type: int) in all cases. The attachment
> > removes the dummy definitions of these ioctls in driver/block/
> > scsi_ioctl.c so they fall through to the scsi mid level which
> > correctly implements them (at least in terms of lk 2.4).
>
> I'm not sure this is the correct thing to do. These ioctls may be there
> because cdrecord is using them. In the new scheme, you can record a CD
> without ever troubling the scsi mid-layer, so if cdrecord wants them, they
> have to be provided in some fashion without relying on a fall through.
>
> I've copied Jens on this mail, since he's the one that knows this stuff and
> should be able to confirm or deny this suspicion. Jens?
Hmm, I _may_ be wrong but I think the main reason for GET_IDLUN and
GET_BUS_NUMBER in the generic block layer is to stop them from failing
in libscg and thus fooling it into believing we are scsi. You would need
to check libscg/scsi-linux-sg.c to be sure.
For one thing, we need to maintain the behaviour we have now of _not_
failing them for ata devices. If you want to pass them down to SCSI as
well and get the right id/lun and bus, fine, but don't break the ata
one.
--
Jens Axboe
^ permalink raw reply
* Re: using 2 TB in real life
From: Anders Henke @ 2002-12-12 17:48 UTC (permalink / raw)
To: Bryan O'Sullivan; +Cc: linux-kernel
In-Reply-To: <1039713776.16887.4.camel@camp4.serpentine.com>
On Dec 12th 2002, Bryan O'Sullivan wrote:
> On Thu, 2002-12-12 at 04:03, Mike Black wrote:
> > Looks like it's already handled in 2.5.
> > Here's a patch for 2.4:
> > http://www.gelato.unsw.edu.au/patches-index.html
>
> The result of the device size calculation that Anders complained about
> in 2.4.20 was wrong in a different way in Peter's >2TB patch, last I
> looked. I don't think Peter's patch is necessary for a 1.9TB device,
> anyway.
Peter's patch is not necessary for a 1.9TB device, but (from a quick
glance at the source) should fix the display problem I mentioned.
Personally I've no problem using 2.4.20 without this patch applied,
although sd.c makes 1.9TB devices look as being something coming
from a very dark corner of the universe ...
I knew of the 2 TB limit before, but the strange output brought me
to extensively test both xfs and ext3 on it before writing any
important data on the device. Other people might assume that Linux simply
cannot handle (scsi/fc) devices larger than 0.5 TB or think Linux of
being of less quality than $other_operating_system ("they claim 2 TB is
the limit, but it somehow chokes at only 0.5 TB").
It would be a very kind thing if someone knows how to fix sd.c that
way would do it before such ideas arise - unluckily, I don't have the
in-depth knowledge to do this, so I'm sending this as a notice to
linux-kernel (as this is the place where I believe the ones are who
know how to do fix it).
Regards,
Anders
--
http://sysiphus.de/
^ permalink raw reply
* Re: Success! TWO questions remain
From: Ken Koster @ 2002-12-12 17:40 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <3DF8AA6B.6000303@voicenet.com>
On Thursday 12 December 2002 07:25, Margaret Leber wrote:
> Hamish Moffatt wrote:
And I wrote and sent with a typical US centric view without thinking that
Hamish is not in the US. Take what I said with the appropriate slant.
:-)
Ken, N7IPB
^ permalink raw reply
* Re: Aic7xxx v6.2.22 and Aic79xx v1.3.0Alpha2 Released
From: Jens Axboe @ 2002-12-12 17:38 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Christoph Hellwig, James Bottomley, linux-scsi
In-Reply-To: <261670000.1039713623@aslan.btc.adaptec.com>
On Thu, Dec 12 2002, Justin T. Gibbs wrote:
> > On Wed, Dec 11 2002, Christoph Hellwig wrote:
> >> > I have no problem with interfaces changing for good reason, but, for
> >> > example,
> >> > a driver that alread sets unchecked_isa_dma to 0 and uses the PCI dma
> >> > mask shouldn't have to set addition flags (with different names in
> >> > different vendor's trees) to enable HIGHIO. It's yet-another *stupid*
> >> > interface change.
> >>
> >> Maybe you could have complained about that more than one year ago when
> >> the patch came up first?
> >
> > And I still dont see a better way to do it. Remember that this is 2.4
> > and we must be able to toggle the highmem io capability on a per-driver
> > basis easily and default to off until a given piece of hardware (and
> > driver) has been verified.
>
> >From the perspective of a driver that already meets the requirements
> for highio, it is simply frustrating that:
>
> 1) You have to set a flag when you've already told the system you
> dma capabilities.
All drivers blindly copy the setting of the dma mask, typically means
nothing.
> 2) That flag is not documented in hosts.h or in the Documentation directory.
That is true. Name of the member is a good clue, though.
> 3) No warning is given if you use pci_set_dma_mask without setting
> highmem_io so that you know that your driver needs to be updated.
Two different layers. One is the block layer entry, other deals with the
hardware.
> 4) highio requires that all SCSI drivers support single length S/G lists,
> but since single buffers are still allowed by the interfaces, even
> compliant SCSI drivers cannot strip out this code.
This is not a new requirement, it's just spelled out now. The special
casing of an sg request with one entry was silly, imho. And yes you do
have to support both single entry sg requests and non-sg requests. I
wouldn't mind getting rid of that, but this is the 2.4 series and
changes must be kept small(ish).
> > Saying the high io stuff could have been done with zero impact to
> > drivers just shows that you have no idea what you are talking about
> > here and are living in your Justin world again. Tons of drivers needed
> > to be changed to be able to deal with highmem pages sanely.
>
> I'm not doubting that "lots of drivers needed to be updated", but since you
> had to touch these drivers anyway, you could have deprecated all of these
> older stupid interfaces and effected a real cleanup without needing a
> positive "highmem enabled" flag. The subset of devices that used
If I had done that, there was no way we could have had this feature for
2.4. It is just too invasive.
> pci_set_dma_mask() and were not compliant was probably small. Fixing
> them with your initial patch set would have made the proper use of the
> PCI dma API the "marker" for a highmem enabled device. Instead,
Again, way too much work. The concept of the highmem_io flag is simple.
If your driver complies with the pci dma api, set the flag and you are
now handed pages for io up to your pci dma mask. If you either don't
know about the flag or don't use the pci dma api, behaviour is
unchanged.
See this way I didn't need to touch _any_ drivers, and I didn't break
_any_ drivers. Drivers that are compliant just have to set the flag.
> drivers that already were compliant to the PCI dma spec silently
> started bouncing pages again unless you knew about this poorly
> documented flag. <ARGGGGHHHH>
What are you talking about? If you didn't set the flag, behaviour is
*unchanged* from before. You always got highmem pages bounced.
As Christoph said, if you want to influence changes made to the kernel
it doesn't help to whine about them years after they were developed. If
you want to take the back seat to the linux kernel, fine, just dont come
complaining when you miss out on something. Your timing is just
excellent, too. You've even had months of 2.4.20-pre time (highmem stuff
was merged in 2.4.20-pre2, iirc), and the block-highmem patch had
existed in the public and in vendor kernels about a year before that.
--
Jens Axboe
^ permalink raw reply
* Re: Success! TWO questions remain
From: Kelly Black @ 2002-12-12 17:36 UTC (permalink / raw)
To: Linux Hams mailing list
In-Reply-To: <Pine.LNX.4.33.0212120924130.1291-100000@wapiti.tc.fluke.com>
On Thu, 2002-12-12 at 11:27, Curt Mills, WE7U wrote:
> On Thu, 12 Dec 2002, Margaret Leber wrote:
>
> > Hamish Moffatt wrote:
> >
> > > Compression is still hiding the data and I would say breaks the rules.
> > > Better solution: use SSH. You can have public key authentication (no
> > > cleartext passwords) without any encryption or compression.
> >
> > Is encrypting even a password permitted outside of control of space
> > stations?
>
How about using OPIE: (One time use passwords with server / client and
no need for encryption).
http://packages.debian.org/stable/admin/opie-server.html
http://packages.debian.org/stable/admin/opie-client.html
http://packages.debian.org/unstable/libs/libpam-opie.html
Kelly Black
KB0GBJ
^ permalink raw reply
* Re: Success! TWO questions remain
From: Ken Koster @ 2002-12-12 17:34 UTC (permalink / raw)
Cc: linux-hams
In-Reply-To: <3DF8AA6B.6000303@voicenet.com>
On Thursday 12 December 2002 07:25, Margaret Leber wrote:
> Hamish Moffatt wrote:
> > Compression is still hiding the data and I would say breaks the rules.
Compression is not breaking the rules and hasn't been for a long time.
NOS, JNOS, FBB and others all use compression for forwarding mail and
it's perfectly legal. We've been doing this now for more than a decade.
> > Better solution: use SSH. You can have public key authentication (no
> > cleartext passwords) without any encryption or compression.
SSH does do encryption and optionally can do compression as well. From
the SSH man page " It (ssh) is intended to replace rlogin and rsh, and
provide secure encrypted communications between two untrusted hosts over an
insecure network."
> Is encrypting even a password permitted outside of control of space
> stations?
Passwords for the purpose of remote control (repeaters, remote packet
systems etc.) have been legally used for a long time. With the advent of
Linux lots of us have been using SSH to control and administer remote
packet sites. While the fact that SSH also encrypts the rest of your
communication besides the password might be considered by some to be
a violation, most of us consider that traffic to also be part of 'control'
and in all the years we've been doing this the FCC has never disabused
any of us of that idea. :-)
>
> 73 de Maggie K3XS
Ken, N7IPB
http://wetnet.net
^ permalink raw reply
* Re: Re: [Alsa-user] fm801 driver status?
From: Takashi Iwai @ 2002-12-12 17:32 UTC (permalink / raw)
To: Friedrich Ewaldt; +Cc: alsa-user, alsa-devel
In-Reply-To: <3DF8B8FA.3040009@gmx.de>
At Thu, 12 Dec 2002 17:27:38 +0100,
Friedrich Ewaldt wrote:
>
> Hi,
> many thanks for your quick reply! Here's some more info:
>
> Mandrake Control Center recognices the card as follows (partly in
> german, sorry, but perhaps that's no problem in ERL/NUE ;-) ):
>
> Hersteller: Fortemedia, Inc
> Bus: PCI
> Bus: 1319:801:1319:1319
> Standort auf den Bus: 0:b:0
> Beschreibung: Xwave QS3000A [FM801]
> Modul: snd-fm801
> Medienklasse: MULTIMEDIA_AUDIO
>
> I had no alsa installed while running hardware detection.
you can check this also via lspci command.
in the output of lspci in your last mail, the i/o ports and irq are
missing. please check again?
> The soundcard is working correctly under win98 without the need to
> change any hardware or bios settings.
> win98 reports:
> fm801 pci audio, IRQ 10, I/O: EC00-EC7F
> plus
> fm801 pci audio, IRQ 11
> and 'no conflicts'. I.e. win98 shows up the same IRQs used as lspci,
> that should be correct, then. But lspci doesn't name any memory regions
> used by this card. Do you have any idea what I could try? (I'll test
> some other bios settings, mounting the card in another slot when I find
> some spare time).
what is the bios configuration? pnp os is yes? then set it to no.
is ACPI enabled on kernel?
Takashi
-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/
^ permalink raw reply
* Problems with un-masqueraded packets
From: Eduard Calvo (B-teljpa) EXP JAN 03 @ 2002-12-12 17:29 UTC (permalink / raw)
To: netfilter-devel
Hi gurus!
I have made a ip queue handler wich is capable to do SNAT before routing
with the forwarded packets. In POSTROUTING, I do MASQUERADING over the nat'ed
addresses. Could someone tell me the way the un-masked paquets traverse the
netfilter hooks and when their source addres is changed? My box is doing
something strange because it does not replace the source address with the
address the packet has when it was masqued ( I mean, the address I put by
force ); it replace the address with the ORIGINAL address the packet has (
before I changed it). This surprise me a lot. I want to do a tracking of the
packet through my box, but I do not understant the way it goes.
Do you have any idea?
Thanks in advanced.
Eduard.
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
^ permalink raw reply
* Re: NFS mounted rootfs possible via PCMCIA NIC ?
From: Andrew Morton @ 2002-12-12 17:35 UTC (permalink / raw)
To: Andreas Schaufler; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212121829.42237.andreas.schaufler@gmx.de>
Andreas Schaufler wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > > Hello list,
> > >
> > > I am trying to configure a notebook with a PCMCIA NIC to boot over
> > > network. (kernel 2.4.20)
> >
> > Nope. The kernel does the NFS thing before bringing up cardbus.
> >
> > This patch worked, back in the 2.4.17 days. It also fixes some
> > cardbus bugs. I don't immediately recall what they were.
>
> I got the 2.4.17 sources and applied the patch. yenta.c and main.c could not
> be patched automatically, so I tried to apply it by hand line by line.
> Unfortunately when I boot a kernel compiled witch this modified sources I get
> an "Unable to handle kernel pagin request at virtual address 0000413d"
>
> Maybe this patch is to be used on some Pre Version of 2.4.17 ?!?!
>
Sorry, that patch was against 2.4.20. It was last tested in 2.4.17.
^ permalink raw reply
* Re: Success! TWO questions remain
From: Curt Mills, WE7U @ 2002-12-12 17:27 UTC (permalink / raw)
To: Margaret Leber; +Cc: Hamish Moffatt, linux-hams
In-Reply-To: <3DF8AA6B.6000303@voicenet.com>
On Thu, 12 Dec 2002, Margaret Leber wrote:
> Hamish Moffatt wrote:
>
> > Compression is still hiding the data and I would say breaks the rules.
> > Better solution: use SSH. You can have public key authentication (no
> > cleartext passwords) without any encryption or compression.
>
> Is encrypting even a password permitted outside of control of space
> stations?
As I understand it, it's allowed in the U.S. for authentication
purposes (passwords), but not for hiding the rest of the text.
Can't speak for other countries rules.
Compression is also allowed as long as it's a well accepted and
documented protocol that's in use. In other words, it's purpose is
for getting more data through a smaller pipe rather than obscuring
the meaning of the data. One should be able to grab the data and
de-compress it, assuming they have the technical know-how to do so.
As with anything, you'll still get arguments both ways on both
authentication and compression issues. See what the TCP/IP guys are
doing on RF. They use encrypted authentication at times, and
commonly accepted compression as well.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
^ permalink raw reply
* Re: [PATCH] save inverted MAC match
From: Michael Schwendt @ 2002-12-12 17:27 UTC (permalink / raw)
To: netfilter-devel; +Cc: Harald Welte
In-Reply-To: <20021114234340.59dbc60a.rh0209ms@arcor.de>
[-- Attachment #1: Type: text/plain, Size: 544 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In CVS, only the IPv4 code has been fixed. Hopefully this was the
last "missing space in saved rules" bug.
The patch is for current CVS codebase, both IPv6 and IPv4.
It's a bit longer again because it tidies up save() as used by
iptables-save without adding white-space in print() as used by
iptables -L.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
iD8DBQE9+Mby0iMVcrivHFQRAprxAJ4viAlVrnJ9O+78kO+tKOO7XXgu7QCcCdbX
U8auSUapy/8PJFzbW1I95cQ=
=9r4z
-----END PGP SIGNATURE-----
[-- Attachment #2: iptables-CVS-invertmac.patch --]
[-- Type: application/octet-stream, Size: 2876 bytes --]
Add missing space in front of inverted MAC match upon saving rules,
but not upon printing rules.
diff -Naur iptables-CVS-orig/extensions/libip6t_mac.c iptables-CVS/extensions/libip6t_mac.c
--- iptables-CVS-orig/extensions/libip6t_mac.c Thu Dec 12 17:52:50 2002
+++ iptables-CVS/extensions/libip6t_mac.c Thu Dec 12 18:16:37 2002
@@ -86,11 +86,11 @@
return 1;
}
-static void print_mac(unsigned char macaddress[ETH_ALEN], int invert)
+static void print_mac(unsigned char macaddress[ETH_ALEN])
{
unsigned int i;
- printf("%s%02X", invert ? "!" : "", macaddress[0]);
+ printf("%02X", macaddress[0]);
for (i = 1; i < ETH_ALEN; i++)
printf(":%02X", macaddress[i]);
printf(" ");
@@ -110,17 +110,23 @@
const struct ip6t_entry_match *match,
int numeric)
{
+ struct ip6t_mac_info *info = (struct ip6t_mac_info *)match->data;
+
printf("MAC ");
- print_mac(((struct ip6t_mac_info *)match->data)->srcaddr,
- ((struct ip6t_mac_info *)match->data)->invert);
+ if ( info->invert )
+ printf("!");
+ print_mac(info->srcaddr);
}
/* Saves the union ip6t_matchinfo in parsable form to stdout. */
static void save(const struct ip6t_ip6 *ip, const struct ip6t_entry_match *match)
{
+ struct ip6t_mac_info *info = (struct ip6t_mac_info *)match->data;
+
printf("--mac-source ");
- print_mac(((struct ip6t_mac_info *)match->data)->srcaddr,
- ((struct ip6t_mac_info *)match->data)->invert);
+ if ( info->invert )
+ printf("! ");
+ print_mac(info->srcaddr);
}
static
diff -Naur iptables-CVS-orig/extensions/libipt_mac.c iptables-CVS/extensions/libipt_mac.c
--- iptables-CVS-orig/extensions/libipt_mac.c Thu Dec 12 17:54:07 2002
+++ iptables-CVS/extensions/libipt_mac.c Thu Dec 12 18:14:51 2002
@@ -86,11 +86,11 @@
return 1;
}
-static void print_mac(unsigned char macaddress[ETH_ALEN], int invert)
+static void print_mac(unsigned char macaddress[ETH_ALEN])
{
unsigned int i;
- printf("%s%02X", invert ? "! " : "", macaddress[0]);
+ printf("%02X", macaddress[0]);
for (i = 1; i < ETH_ALEN; i++)
printf(":%02X", macaddress[i]);
printf(" ");
@@ -110,17 +110,23 @@
const struct ipt_entry_match *match,
int numeric)
{
+ struct ipt_mac_info *info = (struct ipt_mac_info *)match->data;
+
printf("MAC ");
- print_mac(((struct ipt_mac_info *)match->data)->srcaddr,
- ((struct ipt_mac_info *)match->data)->invert);
+ if ( info->invert )
+ printf("!");
+ print_mac(info->srcaddr);
}
/* Saves the union ipt_matchinfo in parsable form to stdout. */
static void save(const struct ipt_ip *ip, const struct ipt_entry_match *match)
{
+ struct ipt_mac_info *info = (struct ipt_mac_info *)match->data;
+
printf("--mac-source ");
- print_mac(((struct ipt_mac_info *)match->data)->srcaddr,
- ((struct ipt_mac_info *)match->data)->invert);
+ if ( info->invert )
+ printf("! ");
+ print_mac(info->srcaddr);
}
static
^ permalink raw reply
* Re: RH 8.0 vs. RH7.3 driver issues
From: arun4linux @ 2002-12-12 17:20 UTC (permalink / raw)
To: Harlan Jillson, linux-kernel
HZ value for i686 has been modified from 100 to 512 in RH 8.0.
If you use this HZ value directly in your driver and , it could be a problem.
Warm Regards
Arun
"Harlan Jillson" wrote:
hi all,
I just subscribed to the list, and am looking for some suggestions.
I have a device driver for a RS485 card that does microlan
communications between several devices. The driver was written a couple
of years ago using the 2.2 kernel in RH 6.1. It's was updated for 2.4
kernel when RH7.3 was released and has been working fine. RH8.0 is
apparently a different story, as there appears to be problems with
scheduled timeouts (polling intervals) and maybe some interrupt issues.
My question is are there any known problems ( RH kernel 2.4.18-3)? I
know I'm dealing the revamps in the scheduler and timer areas and then
there's the shift from gcc 2.96 to 3.2.
Thanks for any suggestions,
Harlan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Get Your Private, Free E-mail from Indiatimes at http://email.indiatimes.com
Buy the best in Movies at http://www.videos.indiatimes.com
Change the way you talk. Indiatimes presents Valufon, Your PC to Phone service with clear voice at rates far less than the normal ISD rates. Go to http://www.valufon.indiatimes.com. Choose your plan. BUY NOW.
^ permalink raw reply
* Re: "bio too big" error
From: Wil Reichert @ 2002-12-12 17:33 UTC (permalink / raw)
To: Joe Thornber; +Cc: kernel list
In-Reply-To: <20021212091209.GA1299@reti>
> ie. previously we were accidentally comparing bytes with sectors to
> verify the device sizes. So either I'm being very stupid (likely) and
> the above patch is bogus, or you really don't have room for this lv.
> Can you send me 3 bits of information please:
Well, it works fine w/ the 2.4 kernel & prior 2.5's, I think my lv is
fine...
> 1) disk/partition sizes for your PVs
spans 4 entire discs and one partition
Disk /dev/discs/disc4/disc: 80.0 GB, 80039116800 bytes
Disk /dev/discs/disc1/disc: 123.5 GB, 123522416640 bytes
Disk /dev/ide/host2/bus1/target0/lun0/disc: 100.0 GB, 100030242816 bytes
Disk /dev/ide/host2/bus0/target1/lun0/disc: 10.1 GB, 10110320640 bytes
/dev/discs/disc0/part4 40072 119150 39855816 8e Linux LVM
Dunno if it matters, but the 80G is 2 striped 40s on a 3ware controller,
the 120, 100, and 10 are on a Promise U133 card, and the 40 gig
partition is on the native VIA controller. Top it all of this is an SMP
box.
> 2) an LVM2 backup of the metadata (the nice readable ascii one).
/etc/lvm/backup/cheese_vg -
# Generated by LVM2: Tue Dec 10 21:11:37 2002
contents = "Text Format Volume Group"
version = 1
description = "Created *after* executing 'vgconvert -M2 cheese_vg'"
creation_host = "darwin" # Linux darwin 2.4.19 #1 SMP Wed Nov 13
16:54:28 EST 2002 i686
creation_time = 1039572697 # Tue Dec 10 21:11:37 2002
cheese_vg {
id = "WF3vAx-k1r3-NUjU-az7z-I4SM-oorx-rvoYSt"
seqno = 1
status = ["RESIZEABLE", "READ", "WRITE"]
system_id = "darwin1025684717"
extent_size = 32768 # 16 Megabytes
max_lv = 256
max_pv = 256
physical_volumes {
pv0 {
id = "XFexK7-KqnW-dt7I-JHfB-gC8t-8Z45-RLiCEW"
device = "/dev/discs/disc4/disc" # Hint
only
status = ["ALLOCATABLE"]
pe_start = 33152
pe_count = 4769 # 74.5156 Gigabytes
}
pv1 {
id = "7swUJv-wGiq-9uCz-xiKK-owvf-p77g-zGU1C5"
device = "/dev/discs/disc1/disc" # Hint
only
status = ["ALLOCATABLE"]
pe_start = 33152
pe_count = 7361 # 115.016 Gigabytes
}
pv2 {
id = "z1Zxq5-X1JX-q08r-epqS-T0V7-003q-admD5T"
device =
"/dev/ide/host2/bus1/target0/lun0/disc"# Hint only
status = ["ALLOCATABLE"]
pe_start = 33152
pe_count = 5961 # 93.1406 Gigabytes
}
pv3 {
id = "zfuSRQ-mYYI-pGHR-9Mu2-uFWu-JQiH-JZyO7I"
device = "/dev/discs/disc0/part4" # Hint
only
status = ["ALLOCATABLE"]
pe_start = 33152
pe_count = 2431 # 37.9844 Gigabytes
}
pv4 {
id = "TNYATl-VrjS-Dt4T-e906-Ilb3-bgu7-JQS1sb"
device =
"/dev/ide/host2/bus0/target1/lun0/disc"# Hint only
status = ["ALLOCATABLE"]
pe_start = 33152
pe_count = 601 # 9.39062 Gigabytes
}
}
logical_volumes {
blah {
id = "000000-0000-0000-0000-0000-0000-000000"
status = ["READ", "WRITE", "VISIBLE"]
allocation_policy = "next free"
read_ahead = 1024
segment_count = 7
segment1 {
start_extent = 0
extent_count = 4769 # 74.5156
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
segment2 {
start_extent = 4769
extent_count = 1409 # 22.0156
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv2", 4552
]
}
segment3 {
start_extent = 6178
extent_count = 2255 # 35.2344
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv3", 0
]
}
segment4 {
start_extent = 8433
extent_count = 7361 # 115.016
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv1", 0
]
}
segment5 {
start_extent = 15794
extent_count = 4552 # 71.125
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv2", 0
]
}
segment6 {
start_extent = 20346
extent_count = 176 # 2.75 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv3", 2255
]
}
segment7 {
start_extent = 20522
extent_count = 601 # 9.39062
Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv4", 0
]
}
}
}
}
> 3) The version of LVM that *created* the lv.
1.0.3, I **think**. I know it rev'd to 1.0.4 or 1.0.5 before I added
another disc or two. Upgraded to lvm2 a couple months back. Just
recently did a 'vgconvert -M2 cheese_vg' to see if that helped things,
but didn't seem to matter.
Wil
^ permalink raw reply
* Re: Success! TWO questions remain
From: Curt Mills, WE7U @ 2002-12-12 17:24 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <20021212132801.GA9699@silly.cloud.net.au>
On Fri, 13 Dec 2002, Hamish Moffatt wrote:
> Compression is still hiding the data and I would say breaks the rules.
> Better solution: use SSH. You can have public key authentication (no
> cleartext passwords) without any encryption or compression.
Make sure to carefully set up SSH to do encrypted authentication but
clear-text everything else. By default it encrypts everything going
across the pipe.
--
Curt Mills, WE7U hacker_NO_SPAM_@tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto: A tax on people who are bad at math!"
"Windows: Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me: I picked the coordinate system!"
^ permalink raw reply
* 2.5.51-bk1-wli-1
From: William Lee Irwin III @ 2002-12-12 17:30 UTC (permalink / raw)
To: linux-kernel
Reorganized the patches, fixed some bugs, and so on. Available from:
ftp://ftp.kernel.org/pub/linux/kernel/people/wli/kernels/2.5.51-bk1-wli-1/
Notable events:
(1) bugfix for unconditionally setting nr_ioapics = 2
reported by Zwane Mwaikambo
(2) bugfix for misaligned order > 0 frees in NUMA-Q highpage init.
(3) dropped manfred's slab changes; they're no longer needed
(4) no preallocation of pmd's in the pgd ctor; they exhibited
extremely poor fragmentation characteristics when
that was done. Just slab allocate pmd's in pgd_alloc().
I never really commented on the theme of the tree. It's basically a
bunch of things that are obvious to me how to do and a place to dump
patches that don't really fit into other trees (e.g. -mm), though I
think some of the NUMA-Q stuff might eventually get thrown over the
wall in the direction of -mjb. =) Sound bite: misc patches from wli.
The net effect is that some odd bootstrapping, wait table hashing,
memory initialization, and tasklist scan removal patches landed here.
Other stuff will crop up as I poke around the tree.
01_driverfs_oops
fix for still-broken driverfs memblk and node registration.
I suspect this might hit mainline soon.
02_numaq_io
Workaround for PCI bridges on different PCI segments
with clashing bus numbers until it's fixed (by me). Drop
IO-APIC's and PCI buses off node 0 onto the floor. Bugfix
to set nr_ioapics only if (clustered_apic_mode) and take
min(2, nr_ioapics) to avoid elevating nr_ioapics. Some
NUMA-Q PCI code may appear soon to replace this...
03_do_sak
Remove tasklist iteration from __do_SAK(); it's simply trying
to kill off tasks in a given session; use for_each_task_pid().
04_proc_super
proc_fill_super() is iterating over the tasklist because there
is no count of processes (only threads). Use a process counter.
05_cap_set_pg
cap_set_pg() is iterating over the tasklist in search of tasks
within a process group; use for_each_task_pid().
06_vm86
vm86 wants to clean up references to tasks. Do so by cleaning
up stale references in release_thread(), not by GC that walks
the tasklist comparing (possibly reused) task_struct pointers.
This was originally part of a bugfix in -dj only half of which
made it to mainline.
07_uml_get_task
UML's get_task() is looking for a task with a given pid; use
find_task_by_pid() instead of walking the tasklist.
08_numaq_mem_map
Free higher-order pages in NUMA-Q highmem mem_map initialization
instead of freeing order 0 pages at a time. New bugfix here that
fixes some improperly-aligned frees. There's an irritated nested
min() duplicate const warning.
09_numaq_pgdat
Allocate pgdats from node-local memory on NUMA-Q
10_has_stopped_jobs
Remove the unused has_stopped_jobs() from kernel/exit.c
and rename __has_stopped_jobs() to has_stopped_jobs().
11_inode_wait
Increase the too-small inode wait table's size.
12_pgd_ctor
Use slab ctor's for pgd's and pmd's on PAE i386 boxen.
One of the primary benefits is that pmd's are actually
accounted (via /proc/slabinfo) so their lowmem consumption
is directly visible.
^ permalink raw reply
* Re: NFS mounted rootfs possible via PCMCIA NIC ?
From: Andreas Schaufler @ 2002-12-12 17:29 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux Kernel Mailing List
In-Reply-To: <1039648320.18467.49.camel@irongate.swansea.linux.org.uk>
...
> PCMCIA relies in part on user space. You can do this, it involves
> building a large initrd with a dhcp client on it that sets up pcmcia,
> then nfs mounts stuff, then pivot_root()'s into it. Its not exactly
> trivial
Thanks for your reply. I get the basic idea from what you say. But what do you
mean by pivot_root()'ing into it ?!?
I'll try Andrew Morton's suggestion first, because it sounds easier. If I
can't get it running I'll try your suggestion.
regards
-Andreas
^ 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.