* Re: remove usage of __MOD_XXX_USAGE_COUNT and derivatives
From: Anders Fugmann @ 2003-01-10 15:21 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20030110134959.GE9467@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> On Fri, Jan 10, 2003 at 02:49:31PM +0100, Anders Fugmann wrote:
>
> I don't think that this is necessarry. What is in fact necessarry, is
> increasing the module use count for every rule created. Otherwise it
> would state 'iptable_filter:unused' in case you had 10 dropping rules.
> This used to be the old behaviour, but confused a couple of users... so
> we decided to change it.
Ok - I will split my answer up into two parts.
1. It seems that we agree upon modules should not have their module
count increased because a new module is loaded. This is the current case.
2. If the general design goal is to have modules reflect all rules, I
guess that the sum of all module counts should be equal or greater than
the total number of rules. If this is the case, then where which module
should be increased when inserting the rule "iptables -A INPUT". In
general - Should not iptables_filter's module count be incremented for
every inserted rule in the filter tabel (Same goes for NAT and MANGLE).
I'm asking, as I'm willing to spend some time understanding the system,
and make patches for Netfilter.
Regards
Anders Fugmann
^ permalink raw reply
* Re: [2.4.20] e1000 as module gives unresolved symbol _mmx_memcpy
From: Alan Cox @ 2003-01-10 16:15 UTC (permalink / raw)
To: Jurgen Kramer; +Cc: Linux Kernel Mailing List
In-Reply-To: <1042211459.2706.9.camel@paragon.slim>
On Fri, 2003-01-10 at 15:10, Jurgen Kramer wrote:
> a) a kernel build for a VIA C3 doesn't use MMX, userspace programs can
> still use it
Basically true. It might be instructive to do more benching on this with
the C3 and MMX especially if the new cores add full prefetch stuff
> b) Both kernel and userspace can't use MMX any more
MMX is designed to need no OS support. SSE/SSE2 do need OS helpers but
not MMX.
^ permalink raw reply
* [PATCH] 2.5.55 fix etherleak in 8390.c
From: Rudmer van Dijk @ 2003-01-10 15:29 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel
Hi,
this is the fix which went in 2.4.21-pre3-ac2, rediffed against 2.5.55
Rudmer
--- linux-2.5.55/drivers/net/8390.c.orig 2003-01-10 16:23:44.000000000 +0100
+++ linux-2.5.55/drivers/net/8390.c 2003-01-10 16:23:00.000000000 +0100
@@ -270,6 +270,7 @@
struct ei_device *ei_local = (struct ei_device *) dev->priv;
int length, send_length, output_page;
unsigned long flags;
+ char scratch[ETH_ZLEN];
length = skb->len;
@@ -341,7 +342,15 @@
* trigger the send later, upon receiving a Tx done interrupt.
*/
- ei_block_output(dev, length, skb->data, output_page);
+ if (length == send_length)
+ ei_block_output(dev, length, skb->data, output_page);
+ else
+ {
+ memset(scratch, 0, ETH_ZLEN);
+ memcpy(scratch, skb->data, skb->len);
+ ei_block_output(dev, ETH_ZLEN, scratch, output_page);
+ }
+
if (! ei_local->txing)
{
ei_local->txing = 1;
@@ -373,7 +382,14 @@
* reasonable hardware if you only use one Tx buffer.
*/
- ei_block_output(dev, length, skb->data, ei_local->tx_start_page);
+ if(length == send_length)
+ ei_block_output(dev, length, skb->data, ei_local->tx_start_page);
+ else
+ {
+ memset(scratch, 0, ETH_ZLEN);
+ memcpy(scratch, skb->data, skb->len);
+ ei_block_output(dev, ETH_ZLEN, scratch, ei_local->tx_start_page);
+ }
ei_local->txing = 1;
NS8390_trigger_send(dev, send_length, ei_local->tx_start_page);
dev->trans_start = jiffies;
^ permalink raw reply
* Re: Re: NFS as a Cluster File System.
From: Brian Tinsley @ 2003-01-10 15:23 UTC (permalink / raw)
To: Lever, Charles; +Cc: Lorn Kay, nfs, linux-ha
In-Reply-To: <6440EA1A6AA1D5118C6900902745938E07D551DF@black.eng.netapp.com>
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
Lever, Charles wrote:
>>-----Original Message-----
>>From: Brian Tinsley [mailto:btinsley@emageon.com]
>>Sent: Thursday, January 09, 2003 4:11 PM
>>To: Lorn Kay
>>Cc: nfs@lists.sourceforge.net; linux-ha@muc.de
>>Subject: [NFS] Re: NFS as a Cluster File System.
>>
>>> Linux clients can use TCP instead of UDP.
>>>
>>>
>>Although I haven't had problems with this in our lab, I
>>believe the NFS authors still consider this experimental.
>>
>>
>
>the Linux NFS client support for TCP is not experimental.
>perhaps less mature than UDP, but definitely not experimental.
>
>the server, OTOH, sports brand new support for TCP. is that
>what you were referring to?
>
>
Yes, sorry to confuse the issue.
--
-[========================]-
-[ Brian Tinsley ]-
-[ Chief Systems Engineer ]-
-[ Emageon ]-
-[========================]-
[-- Attachment #2: Type: text/html, Size: 1554 bytes --]
^ permalink raw reply
* RE: handling of s-record images by bootloader
From: Zajerko-McKee, Nick @ 2003-01-10 15:22 UTC (permalink / raw)
To: 'atul srivastava', linux-mips
I had a simular problem. I ended up writing my own code for my
platform. Here is a description of s-records:
http://www.amelek.gda.pl/avr/uisp/srecord.htm
-----Original Message-----
From: atul srivastava [mailto:atulsrivastava9@rediffmail.com]
Sent: Friday, January 10, 2003 5:17 AM
To: linux-mips@linux-mips.org
Subject: handling of s-record images by bootloader
Hello .
A quick question..
I have developed a primitive bootloader for custom board, that is
successfuly doing the board bringup and loads linux os image
currently through serial link (kermit) only.
network link is also likely to be up soon.
but through serial it loads kernel image only in raw binary
format.
now i want to extend this for s-record images as well..
I am umware that, how differently s-record image need to be
handled..?
i just need some idea or if possible any example code for that..
Best Reagards,
Atul
^ permalink raw reply
* Re: [PATCH] ne.c 8139too.c to fix CERT VU#412115, 2.4.20
From: Alan Cox @ 2003-01-10 16:19 UTC (permalink / raw)
To: David McCullough; +Cc: Linux Kernel Mailing List, becker, jgarzik
In-Reply-To: <20030111005234.A4803@beast.internal.moreton.com.au>
On Fri, 2003-01-10 at 14:52, David McCullough wrote:
> Hi all,
>
> Here's a patch for the ne2000 driver (ne.c) and the RealTek driver
> (8139too.c) in the 2.4.20 kernel to fix the CERT vulnerability VU#412115:
>
> http://www.kb.cert.org/vuls/id/412115
See Marcelo pre tree and -ac tree. I think we have them all covered
between the -ac tree and Marcelo's BK stuff
> For interest, the smc9194 and FEC ethernet drivers appear to be ok.
> Please CC me on any replies,
FEC I agree with. SMC9194 I believe needs fixing (and is fixed in the
-ac tree).
Alan
^ permalink raw reply
* BLKBSZSET still not working on 2.4.18 ?
From: Ludovic Drolez @ 2003-01-10 15:32 UTC (permalink / raw)
To: linux-kernel
Hi !
I'm trying to backup a partition on an IDE drive which has an odd number
of sectors (204939). With a stock open/read you cannot access the last
sector, and that why I tried the BLKBSZSET ioctl to set the basic read
block size to 512 bytes. I verified the writen value with BLKBSZGET
ioctl, but I still cannot read this last sector !
I've tried also this:
- FreeBSD : works but it don't want to port all my software to it
- raw devices: can't read the last sector:
# raw /dev/raw1 /dev/hda2
# dd if=/dev/raw1 of=C bs=512
dd: reading `/dev/raw1': No such device or address
204938+0 records in
204938+0 records out
What can it do ? Wait for a patch in 2.5.xxx ?
TIA,
Ludovic Drolez.
^ permalink raw reply
* Re: Definitions for c_cflag etc. in termbits.h???
From: Wolfgang Denk @ 2003-01-10 15:25 UTC (permalink / raw)
To: Steven Scholz; +Cc: LinuxPPC
In-Reply-To: <3E1EE23F.5BC310F3@imc-berlin.de>
Hi Steven,
in message <3E1EE23F.5BC310F3@imc-berlin.de> you wrote:
>
> E.g. the DEFINEs of c_iflags appear to me as decimal values!?
>
> /* c_iflag bits */
> #define IGNBRK 0000001
> #define BRKINT 0000002
> #define IGNPAR 0000004
> #define PARMRK 0000010
> #define INPCK 0000020
> #define ISTRIP 0000040
> #define INLCR 0000100
> #define IGNCR 0000200
> #define ICRNL 0000400
> #define IXON 0001000
> #define IXOFF 0002000
> #define IXANY 0004000
> #define IUCLC 0010000
> #define IMAXBEL 0020000
No, these are octal values, of course.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Definitions for c_cflag etc. in termbits.h???
From: Steven Scholz @ 2003-01-10 15:27 UTC (permalink / raw)
To: LinuxPPC
In-Reply-To: <3E1EE23F.5BC310F3@imc-berlin.de>
Steven Scholz wrote:
>
> Hi there,
>
> I am playing around with UARTs and got completly confused when looking at
> ./include/asm-ppc/termbits.h:
>
> E.g. the DEFINEs of c_iflags appear to me as decimal values!?
>
> /* c_iflag bits */
> #define IGNBRK 0000001
Thanks to you all!
Of course it's octal.
It's friday! Sorry for the noise!
Steven
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Linux KERNEL mailinglist!
From: Jan Harkes @ 2003-01-10 15:36 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <E18WlrH-0000NO-00@fencepost.gnu.org>
On Thu, Jan 09, 2003 at 06:13:07PM -0500, Richard Stallman wrote:
> The GNU system, with Linux added, had a great deal of success, but
> attributing that success entirely to Linux is a misinterpretation of
> the events.
Can we please end this discussion.
Go harass cygwin users that they should call their systems GNU/Windows.
Or the FreeBSD/NetBSD guys that use a gcc compiler. I ran some FSF tools
on my Amiga, does that make it a GNU/Amiga? Same for the guy who got gcc
on 20 floppies for his GNU/Atari ST. How about all those Solaris and
Irix systems where administrators installed GNU tools in /usr/local
(GNU/Solaris and GNU/Irix?).
This mailinglist is about the linux _kernel_, there must be more
apropriate lists for this (/dev/null comes to mind).
Jan
^ permalink raw reply
* Re: XFree86 vs. 2.5.54 - reboot
From: Dave Jones @ 2003-01-10 15:34 UTC (permalink / raw)
To: Bob_Tracy(0000); +Cc: Andrew Morton, linux-kernel
In-Reply-To: <20030110152659.3F04E4EE7@gherkin.frus.com>
On Fri, Jan 10, 2003 at 09:26:59AM -0600, Bob_Tracy(0000) wrote:
> > > > > AMD K6-III 450 running a 2.4.19 kernel with vesafb, XFree86 4.1.0, and
> > > > > a USB mouse works fine. Same setup with a 2.5.54 kernel does a cold
> > > > > reboot when I type "startx".
> > Yup. It must be something else then. Perhaps you should try disabling
> > various DRM/AGP type things in config, see if that helps.
>
> I wrote:
> > 2.5.55 appears to work fine with CONFIG_AGP and CONFIG_DRM undefined.
> > I'll retry with CONFIG_AGP_MODULE next...
>
> CONFIG_AGP_MODULE enabled works fine with CONFIG_AGP_VIA_MODULE. I'll try
> turning everything back on (AGP 3.0 compliance, DRM) and see what happens.
Can you send me lspci output, and agp related msgs from dmesg.
Dave
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
^ permalink raw reply
* Re: Fixed proken MARK target in POM.
From: Anders Fugmann @ 2003-01-10 15:28 UTC (permalink / raw)
To: Harald Welte; +Cc: netfilter-devel
In-Reply-To: <20030110140024.GU1353@sunbeam.de.gnumonks.org>
Harald Welte wrote:
> On Thu, Jan 09, 2003 at 02:07:37PM +0100, Anders Fugmann wrote:
>
>
>>The patch maintains backward compability, and I request that this patch
>>is applied to mainstream (and pushed to the Andrea for kernel
>>inclusion),
>
>
> 1) Where is the compatibility? I cannot see how this code change would
> ensure that
> a) old, unpatched kernel works with new, patched userspace
> b) new, patched kernel works with old, unpatched userspace
> Those two conditions need to be fulfilled, otherwise we cannot make a
> change during the stable kernel series.
I meant compability in form of userspace syntax, but I will make a new
patch that sorts out the things above (if possible).
>
> 2) Which Andrea are you talking about? Therer is no Andrea involved in
> netfilter/iptabls updates.
Andrea Arcangeli (2.4.x maintainer, just to recite what you already
know), but as you wrote in the previous mail, all patches will go
through netfilter-devel (And let the core team choose what to have
included in the kernel).
>
>
>>as I as a software developer of a firewall cannot ask users
>>of the software to appliy patches to POM.
>
>
> I regard this as critic to my recent patch-o-matic announcement, where I
> was asking people to use patch-o-matic. I was talking about
Actually not, but thats ok.
> bugfixes/updates which are in 2.4.20 (or 2.4.21-preX)... but people are
> still running older kernels than that... and they should indeed use
> patch-o-matic for the netfilter fixes.
Agreed. Compability between kernel and userspace should be maintained no
matter version, and patches exist in POM for users of older kernels.
>
> Apart from that, everything in patch-o-matic are new features or
> extensions, which are either not fully stable or we strongly doubt that
> they are useful for the big public. And if somebody wants to test one
> of those non-standard extensions, we can ask people to use patch-o-matic.
Yes. I'm aware of that. My question is "How can a patch be proven stable
enough to be included, and is the functionality provided 'importent'
enough for the general public?
Regards
Anders Fugmann
^ permalink raw reply
* Re: [parisc-linux] unaligned accesses
From: John David Anglin @ 2003-01-10 15:30 UTC (permalink / raw)
To: jsoe0708; +Cc: randolph, parisc-linux
In-Reply-To: <3E1AA8D500000877@ocpmta8.freegates.net>
> >> 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 workaround
> >> or how to fix this kind of pb. Any idea (gcc-3.3?)?
> >
> >eh? what do you mean?
> >
> well I will try to find back the example I encounter (somewhere in jfs-1.0.23
> IIRC)
I think what Randolph is saying is that structures don't provide a machine
independent way of transfering data from one machine to another. If you
want to do that, you need a machine independent specification for the data.
Having worked on code to decode realtime telemetry data from various
spacecraft, I know that you need to be very aware of type sizes, alignment
and endianness issues on each architecture. The same kind of issues come
up in handling graphics data.
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* Re: Ping a DNS???
From: Carl @ 2003-01-10 15:31 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <20030110090952.A303@lnx2.w8mch.ampr.org>
At 09:09 10/01/2003 -0500, Hal MacArgle wrote:
>Greetings: Contemplating an ISP change I thought I'd ping the present
>thence the proposed DNS's to evaluate the round trip time..
>
>The present, 204.97.4.2, returned it's RTT to be expected.. The
>proposed, 65.196.16.3, returned "100% packet loss" - not expected.
>
>Both addresses are in /etc/resolv.conf, but that shouldn't make a
>difference here - IMHO. <grin> Also; since I'm connected to the INet
>via the present ISP my ping testing idea might be a dumb one.
>
>Invoking 'dig' for both addresses I find a difference in the report:
>"ANSWER" is set = 1, on the working site and = 0 on the non-working.
>This is obvious, to me, what's happening but I can't help but
>wonder if that might mean I wont be able to use that site? /Or/ why
>would a SysAdm set his/her site to not support ping? I'm confused.
>
>TIA and thanks,
>
> Hal - in Terra Alta, WV - Slackware GNU/Linux 8.0 (2.4.13)
> haltec@iceweb.net | w8mch@iceweb.net
> Proprietary Formats Unacceptable
>.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
Are you sure the new DNS ip is correct (65.196.16.3).
I tried dig and could only find that it was an address assigned to uunet and nothing else.
ping and traceroute both tell me the "net is unreachable".
--
Carl
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: Ping a DNS???
From: pa3gcu @ 2003-01-10 15:31 UTC (permalink / raw)
To: Hal MacArgle, linux-newbie
In-Reply-To: <20030110090952.A303@lnx2.w8mch.ampr.org>
On Friday 10 January 2003 14:09, Hal MacArgle wrote:
> Greetings: Contemplating an ISP change I thought I'd ping the present
> thence the proposed DNS's to evaluate the round trip time..
>
> The present, 204.97.4.2, returned it's RTT to be expected.. The
> proposed, 65.196.16.3, returned "100% packet loss" - not expected.
You forgot one thing, some ISP's block pings, have you tryed to actually use
65.196.16.3 as your DNS,?? i have and its quick...
Rest deleted, all i did was add 'nameserver 65.196.16.3' as first line to my
/etc/resolv.conf
BTW;
Your replt too field is now ok, but i guess you knew that.
>
> TIA and thanks,
>
> Hal - in Terra Alta, WV - Slackware GNU/Linux 8.0 (2.4.13)
> haltec@iceweb.net | w8mch@iceweb.net
> Proprietary Formats Unacceptable
--
Regards Richard
pa3gcu@zeelandnet.nl
http://people.zeelandnet.nl/pa3gcu/
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" 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.linux-learn.org/faqs
^ permalink raw reply
* Re: [parisc-linux] ibm-disk on a hp 735/125
From: Matthew Wilcox @ 2003-01-10 15:33 UTC (permalink / raw)
To: Nahkola Mikko; +Cc: parisc-linux
In-Reply-To: <20030110145800.GH2160@aurinko.ntc.nokia.com>
On Fri, Jan 10, 2003 at 04:58:00PM +0200, Nahkola Mikko wrote:
> Well, yes on both counts. Any HVD disks should be detected... but at the
> time these boxes were made, there were supposed to be certain differences
> between HP and regular disks. Or maybe that was just HP marketing.
>
> At any rate, there _was_ (and still is, BTW) a way to recognize a HP disk
> by the firmware - and there were differences between "workstation" and
> "server" disks too, _and_ IIRC "workstation" disks weren't "expected to
> work" in servers, the other way round it was "expected to work" but "unsupported"
> or something. Don't remember.
That's right. HP (in common with other big-iron hardware vendors) has
custom disk firmware which has certain guarantees which are useful for
real world issues but slow down benchmarks.
--
"It's not Hollywood. War is real, war is primarily not about defeat or
victory, it is about death. I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk
^ permalink raw reply
* Re: [parisc-linux] kernel compilation
From: Thibaut VARENE @ 2003-01-10 15:33 UTC (permalink / raw)
To: FARINATI,LEANDRO (HP-Brazil,ex1); +Cc: PArisc-linux
In-Reply-To: <9A0482A7BD2506488AD9417C93F3714F010AB58C@xsp01.brazil.hp.com>
On vendredi, jan 10, 2003, at 16:28 Europe/Paris, FARINATI,LEANDRO
(HP-Brazil,ex1) wrote:
> I get in http://ftp.parisc-linux.org/cvs/
I can't find pa13 there.
Anyway, please try with the latest version: 2.4.20-pa18. This bug (if
it's one) may already have been corrected.
FWIW, do not answer me personally, please always CC the m-l.
Thibaut VARENE
The PA/Linux ESIEE Team
http://pateam.esiee.fr/
^ permalink raw reply
* Re: Definitions for c_cflag etc. in termbits.h???
From: Wolfgang Denk @ 2003-01-10 15:33 UTC (permalink / raw)
To: Milliorn Gary-rxcr80; +Cc: LinuxPPC
In-Reply-To: <5725AF6EE9FAD51195DC009027E3770201266556@az33exm35.corp.mot.com>
In message <5725AF6EE9FAD51195DC009027E3770201266556@az33exm35.corp.mot.com> you wrote:
>
> As to why octal, I couldn't hazard a guess...
Most of the original Unix code used octal constants. They were pretty
popular on the PDP computers...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"Most people would like to be delivered from temptation but would
like it to keep in touch." - Robert Orben
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: RME96 driver patch
From: Takashi Iwai @ 2003-01-10 15:36 UTC (permalink / raw)
To: Anders Torger; +Cc: martin-langer, alsa-devel
In-Reply-To: <200301101613.07818.torger@ludd.luth.se>
At Fri, 10 Jan 2003 16:13:07 +0100,
Anders Torger wrote:
>
> As mentioned before, this driver does not yet handle the cases when
> sample rate and other properties is changed in runtime (I don't know if
> ALSA is complete in that respect either).
as far as i've tested before (vari-speed playback on emu10k1 with a
mixer control :), changing runtime->rate wouldn't break
the middle-level layer if the low-level routines recognizes and
handles the change of rates properly.
but it's true that there is no offical way to change such a property
at runtime except for the sequence: stop, reset hw_params, and start.
Takashi
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* Re: Suggestion
From: Valdis.Kletnieks @ 2003-01-10 15:44 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: Harry Sileoni, linux-kernel
In-Reply-To: <15902.50901.407336.44434@harpo.it.uu.se>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
On Fri, 10 Jan 2003 14:12:53 +0100, Mikael Pettersson said:
> Harry Sileoni writes:
> > While fighting for some time with my Dell Inspiron 8100 laptop and a new
> Are you sure you didn't mean ACPI instead? APIC != ACPI but
> people keep confusing the two.
The Dell Latitude C840 (what I have) and the (AFAIK) Inspiron 8100 both use
the NVidia geForce4 Go graphics chipset, and apparently the posted patches
to make nvidia's closed-source drivers work under 2.5 have issues with ACPI
on some platforms. Digging back, I only found like one message on the LKML
archives that mentioned the nvidia drivers don't play nice with ACPI.
Harry - does that match up with what you have?
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* [linux-lvm] Two drives with the same UUID
From: lvm @ 2003-01-10 15:38 UTC (permalink / raw)
To: linux-lvm
[-- Attachment #1: Type: text/plain, Size: 498 bytes --]
If I had a system with a functional LVM configuration (1.0.6ish) and I
were to "duplicate" the drive in it (i.e. dd if=/dev/sda of=/dev/sdb)
and then try to boot that system (with both drives installed and
functional), what would happen?
Of course, because I am asking, I have tried it. :-) During boot LVM
failed to find any logical volumes. Is this expected? It's not
surprising mind you, but I wonder how it was designed to deal with
this situation.
b.
--
Brian J. Murrell
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Linux-fbdev-devel] [RFC][PATCH][FBDEV]: Setting fbcon's windows size
From: Antonino Daplas @ 2003-01-10 15:38 UTC (permalink / raw)
To: James Simmons; +Cc: Linux Fbdev development list, Linux Kernel List
In-Reply-To: <1041864838.955.68.camel@localhost.localdomain>
On Mon, 2003-01-06 at 22:54, Antonino Daplas wrote:
> So, what's needed is a function that calculates timing parameters which
> is generic enough to work with the most common monitors. One solution
> is to use VESA's GTF (Generalized Timing Formula). Attached is a patch
> that implements the formula.
>
James,
Attached is a diff against linux-2.5.54 + your latest fbdev.diff.
Hopefully it's the final installment for the GTF implementation.
The fb_get_mode() function checks for a bit in 'flags' (FB_IGNOREMON) so
it will generate GTF timings regardless of the validity of
info->monspecs. This way, drivers can still use GTF even if they don't
have the operational limits of the monitor. They'll just decide what is
a practical safe limit.
This particular code snippet can be inserted in xxxfb_check_var() after
rounding off var->xres and var->yres.
...
if (fb_validate_mode(var, info)) {
if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
!info->monspecs.dclkmax ||
info->monspecs.hfmax < info->monspecs.hfmin ||
info->monspecs.vfmax < info->monspecs.vfmin ||
info->monspecs.dclkmax < info->monspecs.dclkmin)
fb_get_mode(FB_IGNOREMON | FB_VSYNCTIMINGS, 60, var, info);
else
if (fb_get_mode(FB_MAXTIMINGS, 0, var, info))
return -EINVAL;
}
...
With the above, the driver will switch to a 60Hz refresh rate timings
(safe even for low-end monitors up to 1024x768) if monspecs is invalid.
Other changes: added a few more fields to fb_info.monspecs.
Tony
diff -Naur linux-2.5.54/drivers/video/fbmon.c linux/drivers/video/fbmon.c
--- linux-2.5.54/drivers/video/fbmon.c 2003-01-10 15:17:22.000000000 +0000
+++ linux/drivers/video/fbmon.c 2003-01-10 15:10:44.000000000 +0000
@@ -511,6 +511,9 @@
* refresh rate. Otherwise, it will calculate timings based on
* the flag and accompanying value.
*
+ * If FB_IGNOREMON bit is set in @flags, monitor specs will be
+ * ignored and @var will be filled with the calculated timings.
+ *
* All calculations are based on the VESA GTF Spreadsheet
* available at VESA's public ftp (http://www.vesa.org).
*
@@ -527,22 +530,27 @@
{
struct __fb_timings timings;
u32 interlace = 1, dscan = 1;
- u32 hfmin, hfmax, vfmin, vfmax;
+ u32 hfmin, hfmax, vfmin, vfmax, dclkmin, dclkmax;
/*
* If monspecs are invalid, use values that are enough
* for 640x480@60
*/
- if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+ if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
+ !info->monspecs.dclkmax ||
info->monspecs.hfmax < info->monspecs.hfmin ||
- info->monspecs.vfmax < info->monspecs.vfmin) {
+ info->monspecs.vfmax < info->monspecs.vfmin ||
+ info->monspecs.dclkmax < info->monspecs.dclkmin) {
hfmin = 29000; hfmax = 30000;
vfmin = 60; vfmax = 60;
+ dclkmin = 0; dclkmax = 25000000;
} else {
hfmin = info->monspecs.hfmin;
hfmax = info->monspecs.hfmax;
vfmin = info->monspecs.vfmin;
vfmax = info->monspecs.vfmax;
+ dclkmin = info->monspecs.dclkmin;
+ dclkmax = info->monspecs.dclkmax;
}
memset(&timings, 0, sizeof(struct __fb_timings));
@@ -557,8 +565,8 @@
dscan = 2;
}
- switch (flags) {
- case 0: /* maximize refresh rate */
+ switch (flags & ~FB_IGNOREMON) {
+ case FB_MAXTIMINGS: /* maximize refresh rate */
timings.hfreq = hfmax;
fb_timings_hfreq(&timings);
if (timings.vfreq > vfmax) {
@@ -566,15 +574,15 @@
fb_timings_vfreq(&timings);
}
break;
- case 1: /* vrefresh driven */
+ case FB_VSYNCTIMINGS: /* vrefresh driven */
timings.vfreq = val;
fb_timings_vfreq(&timings);
break;
- case 2: /* hsync driven */
+ case FB_HSYNCTIMINGS: /* hsync driven */
timings.hfreq = val;
fb_timings_hfreq(&timings);
break;
- case 3: /* pixelclock driven */
+ case FB_DCLKTIMINGS: /* pixelclock driven */
timings.dclk = PICOS2KHZ(val) * 1000;
fb_timings_dclk(&timings);
break;
@@ -583,11 +591,12 @@
}
- if (timings.vfreq < vfmin || timings.vfreq > vfmax ||
- timings.hfreq < hfmin || timings.hfreq > hfmax)
+ if (!(flags & FB_IGNOREMON) &&
+ (timings.vfreq < vfmin || timings.vfreq > vfmax ||
+ timings.hfreq < hfmin || timings.hfreq > hfmax ||
+ timings.dclk < dclkmin || timings.dclk > dclkmax))
return -EINVAL;
-
var->pixclock = KHZ2PICOS(timings.dclk/1000);
var->hsync_len = (timings.htotal * 8)/100;
var->right_margin = (timings.hblank/2) - var->hsync_len;
@@ -616,22 +625,27 @@
int fb_validate_mode(struct fb_var_screeninfo *var, struct fb_info *info)
{
u32 hfreq, vfreq, htotal, vtotal, pixclock;
- u32 hfmin, hfmax, vfmin, vfmax;
+ u32 hfmin, hfmax, vfmin, vfmax, dclkmin, dclkmax;
/*
* If monspecs are invalid, use values that are enough
* for 640x480@60
*/
- if ((!info->monspecs.hfmax && !info->monspecs.vfmax) ||
+ if (!info->monspecs.hfmax || !info->monspecs.vfmax ||
+ !info->monspecs.dclkmax ||
info->monspecs.hfmax < info->monspecs.hfmin ||
- info->monspecs.vfmax < info->monspecs.vfmin) {
+ info->monspecs.vfmax < info->monspecs.vfmin ||
+ info->monspecs.dclkmax < info->monspecs.dclkmin) {
hfmin = 29000; hfmax = 30000;
vfmin = 60; vfmax = 60;
+ dclkmin = 0; dclkmax = 25000000;
} else {
hfmin = info->monspecs.hfmin;
hfmax = info->monspecs.hfmax;
vfmin = info->monspecs.vfmin;
vfmax = info->monspecs.vfmax;
+ dclkmin = info->monspecs.dclkmin;
+ dclkmax = info->monspecs.dclkmax;
}
if (!var->pixclock)
diff -Naur linux-2.5.54/include/linux/fb.h linux/include/linux/fb.h
--- linux-2.5.54/include/linux/fb.h 2003-01-10 15:17:37.000000000 +0000
+++ linux/include/linux/fb.h 2003-01-10 15:19:56.000000000 +0000
@@ -240,6 +240,9 @@
__u32 hfmax; /* hfreq upper limit (Hz) */
__u16 vfmin; /* vfreq lower limit (Hz) */
__u16 vfmax; /* vfreq upper limit (Hz) */
+ __u32 dclkmin; /* pixelclock lower limit (Hz) */
+ __u32 dclkmax; /* pixelclock upper limit (Hz) */
+ unsigned gtf : 1; /* supports GTF */
unsigned dpms : 1; /* supports DPMS */
};
@@ -465,6 +468,12 @@
extern int num_registered_fb;
/* drivers/video/fbmon.c */
+#define FB_MAXTIMINGS 0
+#define FB_VSYNCTIMINGS 1
+#define FB_HSYNCTIMINGS 2
+#define FB_DCLKTIMINGS 3
+#define FB_IGNOREMON 0x100
+
extern int fbmon_valid_timings(u_int pixclock, u_int htotal, u_int vtotal,
const struct fb_info *fb_info);
extern int fbmon_dpms(const struct fb_info *fb_info);
^ permalink raw reply
* [Bluez-users] better return code handling in rfcomm command
From: wim delvaux @ 2003-01-10 15:40 UTC (permalink / raw)
To: BlueZ Mailing List
[-- Attachment #1: Type: text/plain, Size: 339 bytes --]
Hi all,
just found out that some errors do not cause rfcomm to retrun with exit != 0
It seems that the 'func' field in the command jump table should return int and
not void.
All commands can then return an error code (probably one that was generate by
an deeper function) and cause exit to return proper return values.
Patch attached
[-- Attachment #2: patch.gz --]
[-- Type: application/x-gzip, Size: 1215 bytes --]
^ permalink raw reply
* Re: [parisc-linux] ibm-disk on a hp 735/125
From: John David Anglin @ 2003-01-10 15:47 UTC (permalink / raw)
To: Joerg Krebs; +Cc: parisc-linux
In-Reply-To: <Pine.GSO.4.51.0301091743500.9837@sunhalle66>
> But now I want to replace the disk with a larger 4,3GB ibm dcas-34330
> disk, but I can't get it be detected by the system, I think i used the
> same jumper settings as on the old seagate drive.
> at the search for potential boot devices nothing appears.
If the ibm drive is not high-voltage differential, you can probably get
a wide to narrow adapter and put it at the end of the narrow SE bus.
Plugging a non-differential drive into a differential bus is not supposed
to damage anything but it does completely disable the bus drivers of
all devices on the bus ;-)
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply
* Re: SSH doesnt properly logout
From: Saint Neon @ 2003-01-10 15:51 UTC (permalink / raw)
To: Carl; +Cc: linux-admin
In-Reply-To: <5.1.1.6.0.20030110144956.01f95bb0@pop3.demon.co.uk>
I am not an expert in SSH, but here is a suggestion
that you would like to try out.
If you use the single-shell method, you will have to
terminate the agent yourself. Instead, use a
sub-shell. Like this.
ssh-agent /bin/bash
(or)
ssh-agent $SHELL
What this does, is it automatically terminates the
agent when you log out. Meaning that it will terminate
the process running in the background too.
Hope this helps,
Neon.
--- Carl <carl@anexia.co.uk> wrote:
> At 15:08 10/01/2003 +0100, axel@pearbough.net wrote:
> >Hi linux admins,
> >
> >I'm observing some strange behaviour concerning ssh
> and logging out from a
> >ssh connection when I put a process in background
> on the remote side.
> >For instance I do the following:
> >
> >* I start a gcc compilation on the remote terminal
> > make bootstrap >& build.log &
> > Then it goes into background.
> >
> >* Now I "logout" but do not return to my local
> terminal, now there is only a
> > blank screen with the cursor in the upper
> left side.
> >
> >Can somebody help me please in understand this
> behaviour or rather help me
> >fix it?
> >
> >
> >Best regards,
> >Axel Siebenwirth
> >-
> >To unsubscribe from this list: send the line
> "unsubscribe linux-admin" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
> Try running it with a nohup
>
> nohup make bootstrap >& build.log &
>
> Running it in the background should still stop it
> when you log out.
>
> --
> Carl
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-admin" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at
http://vger.kernel.org/majordomo-info.html
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
^ 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.