* Re: Problem reading directories
From: Sergey Suleymanov @ 2003-01-08 7:19 UTC (permalink / raw)
To: Linux-MSDOS Mailing list
In-Reply-To: <200301080500.h0850YS02757@jupiter.dyse.net>
>>>>> José Mario Trujillo writes:
José> Hi, I'm running in a Debian Linux dosmeu 1.1.4 and Freedos 8b.
José> I tried to install a propietary aplication that creates a
José> directory tree like c:\#$COMPAC.PRO\COMPAC\ and inside create a
Is C: drive lredired linux path or hdimage? How are you
specify it in dosemu.conf?
--
Sergey Suleymanov
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* opening a charcter device without using filp_open()
From: David Chow @ 2003-01-08 7:29 UTC (permalink / raw)
To: linux-kernel
Hi all,
Is it possible to open a character device in kernel space without
actually openning the device file? Because I don't wan to hold the usage
count of a particular mount or dcache.
This is what I planned to do,
struct file fake_devfile = {0};
struct dentry fake_dentry = {0};
struct inode fake_inode = {0};
/* Link up fake file,dentry, inode */
fake_file.f_dentry=&fake_dentry;
fake_dentry.d_inode=&fake_inode;
Then I will call the f_op of the character device directly, please give
advice. Thanks.
regards,
David Chow
^ permalink raw reply
* RE: Honest does not pay here ...
From: Hell.Surfers @ 2003-01-08 7:29 UTC (permalink / raw)
To: andre, pollard, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
People, I am confident would rather use GPLd drivers in GNU/Linux, without checksums and make their own checksums, NT4 SP6 would get drivers from the makers of the iSCSI cards, its easy to make them, im working on GPLd support for USB under W95.
Dean McEwan, If the drugs don't work, [sarcasm] take more...[/sarcasm].
On Tue, 7 Jan 2003 16:24:12 -0800 (PST) Andre Hedrick <andre@linux-ide.org> wrote:
[-- Attachment #2: Type: message/rfc822, Size: 2176 bytes --]
From: Andre Hedrick <andre@linux-ide.org>
To: Jesse Pollard <pollard@admin.navo.hpc.mil>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Honest does not pay here ...
Date: Tue, 7 Jan 2003 16:24:12 -0800 (PST)
Message-ID: <Pine.LNX.4.10.10301071621210.421-100000@master.linux-ide.org>
On Tue, 7 Jan 2003, Jesse Pollard wrote:
> Not quite the same thing. I'm referring to the hardware design. I've seen too
> much crap hidden in drivers to try and coverup crappy hardware
> design/implementation.
I never said there was hardware involved.
I could add hardware in the form of CAM.
Content Addressable Memory.
> I would presume your cut would come from my willingness to purchace the
> hardware. Your added value is a software demonstration of capability. My
Nope, it is pure software ... my cut is you buying the driver.
If the hardware fails, it is in opensouce drivers.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
-
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/
^ permalink raw reply
* Re: !?!
From: Anton Erofeevskij @ 2003-01-08 7:33 UTC (permalink / raw)
To: Russell Coker, reiserfs-list
In-Reply-To: <200301080818.16061.russell@coker.com.au>
Russell Coker wrote:
>On Wed, 8 Jan 2003 07:53, Anton Erofeevskij wrote:
>
>>in reiserfs filesystem
>>time cat sd1 | ./a.out > sd2
>>0.00user 0.05system 0:01.79elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
>>0inputs+0outputs (131major+43minor)pagefaults 0swaps
>>
>>in ext2 filesystem
>>time cat sd1 | ./a.out > sd2
>>0.00user 0.05system 0:00.95elapsed 2%CPU (0avgtext+0avgdata 0maxresident)k
>>0inputs+0outputs (131major+43minor)pagefaults 0swaps
>>
>
>Try mounting the ReiserFS file system with notail and it should perform a lot
>better for such things.
>
mount -o notail
time no change !
^ permalink raw reply
* RE:Commentary Summary: AKA Andres manipulation...
From: Hell.Surfers @ 2003-01-08 7:41 UTC (permalink / raw)
To: andre, linux-kernel, rms
[-- Attachment #1: Type: text/plain, Size: 239 bytes --]
Attempting to manipulate the community is flawed do not continue subverting it.
Dean McEwan, If the drugs don't work, [sarcasm] take more...[/sarcasm].
On Tue, 7 Jan 2003 21:18:49 -0800 (PST) Andre Hedrick <andre@linux-ide.org> wrote:
[-- Attachment #2: Type: message/rfc822, Size: 6098 bytes --]
From: Andre Hedrick <andre@linux-ide.org>
To: linux-kernel@vger.kernel.org
Subject: Commentary Summary:
Date: Tue, 7 Jan 2003 21:18:49 -0800 (PST)
Message-ID: <Pine.LNX.4.10.10301071844230.421-100000@master.linux-ide.org>
What we have seen is a lot of slide of hand tricks to try and force all
the hardware and software vendors to open source and give it all away.
This is not going to happen.
I tried it and had some success, but it cost me lots of money, time, legal
hassles, but now that the chipsets are modular what will happen?
The latest tricks in our bag:
GPL_ONLY
GPL_ONLY + restrictive kernel system calls.
Rants about derived works.
Is linux the sum of the drivers ?
If all the drivers were gone, what would be left?
Is linux the a derived work from the sum of the drivers?
Is the the source code not that manual to the API?
"Use the Source Luke!"
Is linux going to invoke the DMCA to prevent usage?
What will happen if any one of the developers trying to enforce copyright
under GPL, loses?
Now of to winners and losers:
Linux 2.6/3.0 kernel ships. One distribution present today or created in
the future because of politics or market forces, decides to disable the
GPL_ONLY as to allow binary modules to use all of the kernel services
unrestricted. The include all the source code and patches and follow all
the rules that each one is doing today.
Subtext: If GPL_ONLY is such a big issue for the distributions who employ
and rightfully own the works released, ship their products in this mode?
Of course they do not need to ship the patch, because it is in the kernel
tree shipped. This would add complexity to the enduser, to undo such a
deed. Would the customer switch distributions?
The subtext above describes why the GPL_ONLY will fail.
Remember, under GPL none of us can add restrictions to prevent people from
changing the content of the files redistributed. So it is a given it will
fail, once market forces are applied.
Now move into the embedded appliance space.
This will surely collapse into a black hole if they do not remove the
"GPL_ONLY" properties in the future stable release. So again market
forces are going to undo all the work everyone has tried to enforce like
this was a closed society of developers, similar to Redmond.
Now back to the issue of copyright enforcement since GPL is some what
removed from the issue at the enduser level.
Copyright only protects the actual document and not the content.
Recall my whining about "Vojtech Pavlik <vojtech@suse.cz>", during the
time when "Martin D." was running the show, and everyone jumped on me and
called me a fool for complaining about the file replacement issue?
The reality is that "Vojtech" complied with everything about Copyright
Law, and I had no case at all. What "Vojtech" did was to read my work and
created something new from the idea inside the document. For the most
part it worked just fine and functioned with the same behavior. One
difference is is I lost my copyright on the file, but the "IDEAS" were
transferred to a new file.
Oh and Vojtech, I own you a huge apology for being rude and ugly to you
over that entire series of events. If you can improve on the work, by all
means you should, and please do. I will not can, nor would I stop or
hinder progress again.
Now jump back to the so called "unpublished API", again.
Using the example above between "Vojtech" and myself, if anyone was to
create a full snapshot and create a new work(s) by extracting all the
ideas in the headers into a new set, nothing GPL or Copyright can do to
stop them. What was done is to extract the ideas, not the actual
protected work.
Moving forward with this new snapshot of the API to Linux which is not
subject to any license restrictions or copyright, like it or not that is
the fact! What does this mean in other cases? Could HURD extract all the
IDEA's from Linux and make it extinct? Who knows, but I do know that
should RMS be successfull, that binary modules and freedom are gone.
Since the IDEAS are transformed into a new work, assigned to FSF, oh it
scares me to go further. This could be a reality.
Here comes the boundary nobody wanted to find, except me!
Finding it may make it impossible to use linux for any business model.
Any model with IP or whatever you call it locked into "binary object".
Subtext: "binary object" and not a binary module.
For ease, lets make the new snapshot API "headers" licensed under LGPL.
I will stop for now as I am tired.
However this clearly explains how one can use the kernel API for a
snapshot, but the pain involved is huge.
I am not into this much pain, period.
Flame me if you want, I do not care.
Hate me if you want, I do not care.
Kick me out again, I do not care.
However, each of us should care and think about the above.
Regards,
Andre Hedrick
LAD Storage Consulting Group
-
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/
^ permalink raw reply
* [PATCH] RFC 1812 recommended reject codes Was:[ANNOUNCE] Current netfilter/iptables development
From: Jens Hektor @ 2003-01-08 7:40 UTC (permalink / raw)
To: netfilter-devel
[-- Attachment #1: Type: text/plain, Size: 408 bytes --]
Hi,
I am submitting the patches hoping they are in the correct form
and get into the queue for 2.4.21.
Credits to Maciej Soltysiak also who worked on the same problem.
Best regards, Jens Hektor
--
Jens Hektor, RWTH Aachen, Rechenzentrum, Seffenter Weg 23, 52074 Aachen
Computing Center, Aachen University, network operation & security
mailto:hektor@RZ.RWTH-Aachen.DE, Tel.: +49 241 80 29206, Raum: 2.35
[-- Attachment #2: ipt_REJECT.patch --]
[-- Type: text/plain, Size: 1050 bytes --]
*** linux-2.4.20/include/linux/netfilter_ipv4/ipt_REJECT.h.orig 2002-11-29 07:32:28.000000000 +0100
--- linux-2.4.20/include/linux/netfilter_ipv4/ipt_REJECT.h 2002-11-29 19:42:47.000000000 +0100
***************
*** 9,15 ****
IPT_ICMP_ECHOREPLY,
IPT_ICMP_NET_PROHIBITED,
IPT_ICMP_HOST_PROHIBITED,
! IPT_TCP_RESET
};
struct ipt_reject_info {
--- 9,16 ----
IPT_ICMP_ECHOREPLY,
IPT_ICMP_NET_PROHIBITED,
IPT_ICMP_HOST_PROHIBITED,
! IPT_TCP_RESET,
! IPT_ICMP_ADMIN_PROHIBITED
};
struct ipt_reject_info {
*** linux-2.4.20/net/ipv4/netfilter/ipt_REJECT.c.orig 2002-11-29 07:03:27.000000000 +0100
--- linux-2.4.20/net/ipv4/netfilter/ipt_REJECT.c 2002-11-29 07:07:14.000000000 +0100
***************
*** 308,313 ****
--- 308,316 ----
case IPT_ICMP_HOST_PROHIBITED:
send_unreach(*pskb, ICMP_HOST_ANO);
break;
+ case IPT_ICMP_ADMIN_PROHIBITED:
+ send_unreach(*pskb, ICMP_PKT_FILTERED);
+ break;
case IPT_TCP_RESET:
send_reset(*pskb, hooknum == NF_IP_LOCAL_IN);
case IPT_ICMP_ECHOREPLY:
[-- Attachment #3: ipt_REJECT.patch.help --]
[-- Type: text/plain, Size: 304 bytes --]
Author: Jens Hektor <hektor@rz.rwth-aachen.de>
Status: Trivial.
Adds the possibility of sending RFC 1812 recommended reject codes
into the kernel code. (ICMP destination unreachable, code 13,
see RFC 1812, p 81)
Backward compatibility with older iptables
versions preserved by appending to the enum.
[-- Attachment #4: libipt_REJECT.patch --]
[-- Type: text/plain, Size: 3422 bytes --]
*** iptables-1.2.7a/extensions/libipt_REJECT.c.orig 2002-11-29 19:38:01.000000000 +0100
--- iptables-1.2.7a/extensions/libipt_REJECT.c 2002-12-02 06:51:31.000000000 +0100
***************
*** 7,12 ****
--- 7,14 ----
#include <stdlib.h>
#include <getopt.h>
#include <iptables.h>
+ #include <linux/version.h>
+ #include <sys/utsname.h>
#include <linux/netfilter_ipv4/ip_tables.h>
#include <linux/netfilter_ipv4/ipt_REJECT.h>
***************
*** 35,43 ****
{"icmp-host-prohibited", "host-prohib",
IPT_ICMP_HOST_PROHIBITED, "ICMP host prohibited"},
{"tcp-reset", "tcp-reset",
! IPT_TCP_RESET, "TCP RST packet"}
};
static void
print_reject_types()
{
--- 37,53 ----
{"icmp-host-prohibited", "host-prohib",
IPT_ICMP_HOST_PROHIBITED, "ICMP host prohibited"},
{"tcp-reset", "tcp-reset",
! IPT_TCP_RESET, "TCP RST packet"},
! /* #if to fix compiletime compatibility, adjust version to reflect the include of the kernel patch into the main tree */
! #if ((LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,21) && LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0))||LINUX_VERSION_CODE >= KERNEL_VERSION(2,5,99))
! {"icmp-admin-prohibited", "admin-prohib",
! IPT_ICMP_ADMIN_PROHIBITED, "ICMP administratively prohibited"}
! #endif
};
+ static
+ int icmp_admin_prohib_enabled = 0 ;
+
static void
print_reject_types()
{
***************
*** 46,53 ****
printf("Valid reject types:\n");
for (i = 0; i < sizeof(reject_table)/sizeof(struct reject_names); i++) {
! printf(" %-25s\t%s\n", reject_table[i].name, reject_table[i].desc);
! printf(" %-25s\talias\n", reject_table[i].alias);
}
printf("\n");
}
--- 56,65 ----
printf("Valid reject types:\n");
for (i = 0; i < sizeof(reject_table)/sizeof(struct reject_names); i++) {
! if ((strcmp ( reject_table[i].name, "icmp-admin-prohibited" ) == 0) && icmp_admin_prohib_enabled) {
! printf(" %-25s\t%s\n", reject_table[i].name, reject_table[i].desc);
! printf(" %-25s\talias\n", reject_table[i].alias);
! }
}
printf("\n");
}
***************
*** 103,110 ****
for (i = 0; i < limit; i++) {
if ((strncasecmp(reject_table[i].name, optarg, strlen(optarg)) == 0)
|| (strncasecmp(reject_table[i].alias, optarg, strlen(optarg)) == 0)) {
! reject->with = reject_table[i].with;
! return 1;
}
}
/* This due to be dropped late in 2.4 pre-release cycle --RR */
--- 115,127 ----
for (i = 0; i < limit; i++) {
if ((strncasecmp(reject_table[i].name, optarg, strlen(optarg)) == 0)
|| (strncasecmp(reject_table[i].alias, optarg, strlen(optarg)) == 0)) {
! if (reject_table[i].with==IPT_ICMP_ADMIN_PROHIBITED && !icmp_admin_prohib_enabled) {
! exit_error(PARAMETER_PROBLEM,
! "icmp-admin-prohibited not with this kernel version");
! } else {
! reject->with = reject_table[i].with;
! return 1;
! }
}
}
/* This due to be dropped late in 2.4 pre-release cycle --RR */
***************
*** 174,178 ****
--- 191,205 ----
void _init(void)
{
+ struct utsname buf ;
+ int a, b, c ;
+
+ /* This is to fix run-time compatibility with kernels that
+ are not compatible with this version of iptables */
+ uname(&buf);
+ sscanf (buf.release, "%d.%d.%d", &a, &b, &c);
+ if ((a==2 && b==4 && c>=21) || (a==2 && b==5 && c>=99 ))
+ icmp_admin_prohib_enabled = 1;
+
register_target(&reject);
}
[-- Attachment #5: libipt_REJECT.patch.help --]
[-- Type: text/plain, Size: 511 bytes --]
Author: Jens Hektor <hektor@rz.rwth-aachen.de>
Status: It Works For Me.
This patch adds a new option for --reject-with, namely
"icmp-admin-prohibited" or short "admin-prohib" to enable
RFC 1812 compatible reject codes.
While the actual code to enable this feature is trivial
most of the code in this patch is to preserve backward
compatibility of a new iptables version running or compiling
on an older kernel.
Assumption in this patch is that 2.4.21 and 2.5.99 support
this feature already in the kernel.
^ permalink raw reply
* Re: [Asterisk] DTMF noise
From: Thomas Tonino @ 2003-01-08 7:51 UTC (permalink / raw)
To: Roy Sigurd Karlsbakk; +Cc: linux-kernel
In-Reply-To: <D6889804-2291-11D7-901B-000393950CC2@karlsbakk.net>
Roy Sigurd Karlsbakk wrote:
> so - we DO NOT need a 'simplistic' DTMF decoder.
You need a good one. But good can be simplistic, is what I'm saying.
DTMF was designed to be easy to decode reliably. Complex doesn't automatically
mean better.
I remember reading a more specific version of the message I pointed a pointer
to, but couldn't find it back. But it came down to the devil being in the details.
It probably pays to have someone look at this with old hardware experience in
this. Telco newsgroup perhaps.
Thomas
^ permalink raw reply
* Re: 16 NANDS
From: David Woodhouse @ 2003-01-08 8:14 UTC (permalink / raw)
To: tglx; +Cc: manningc2, m.neiger, 'linux-mtd@lists.infradead.org'
In-Reply-To: <200301072004.45259.tglx@linutronix.de>
tglx@linutronix.de said:
> The functions are not that different, but it's better to have a
> little duplicated code instead of if (buswitdh == x) then else....
> crap.
Bear in mind that if/then/else crap can be hidden inside #defines fairly
effectively, and optimises away perfectly in the case where you compile for
only one buswidth -- unlike out-of-line function calls.
What Nico did with cfi_read() et al is worth considering.
--
dwmw2
^ permalink raw reply
* [U-Boot-Users] Configuring linux kernel for custom board
From: Wolfgang Denk @ 2003-01-08 7:47 UTC (permalink / raw)
To: u-boot
In-Reply-To: <se1bfd85.058@gw_tus_syd3.tus.au.thales>
In message <se1bfd85.058@gw_tus_syd3.tus.au.thales> you wrote:
>
> I'm not to sure if this question is long overdue, but is there a guide
> somewhere to help me with customising linux for my custom board?
Not on this list. This is the U-Boot mailing list. Standard Linux
configuration issues are off topic here.
> At the moment, I have based my MPC860T around the fads860t
> configuration, making changes where I *think* are appropriate (i.e.
> getting rid of the BCSR references). I am concerned with the files I
> have added to the kernel are not "right" and want to verify the process
> of porting linux to a custom board.
It will be difficult to answer such a question anyway, as you first
have to explain exactly what you did and what you need. This will
include a detailed description of your hardware (probably including
the schematics) and your software requirements (devices, driver
sources, ...).
You cannot expect such detailed help on a mailing list. Hire an
expert.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd at denx.de
Another megabytes the dust.
^ permalink raw reply
* dmesg output
From: slaton @ 2003-01-08 7:48 UTC (permalink / raw)
To: linux-smp
Hi,
Per instructions buried within, here is my startup log output, relevant
section. System is dual 2.4ghz Xeon, hyperthreading active in bios, Red
Hat 8.0 with kernel 2.4.18-19.8.0smp (that's red hat's current default 8.0
smp kernel).
***********************
testing the IO APIC.......................
IO APIC #2......
.... register #00: 02008000
....... : physical APIC id: 02
WARNING: unexpected IO-APIC, please mail
to linux-smp@vger.kernel.org
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 00000000
....... : arbitration: 00
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 00F 0F 0 0 0 0 0 1 1 39
02 008 08 0 0 0 0 0 1 1 31
03 00F 0F 0 0 0 0 0 1 1 41
04 00F 0F 0 0 0 0 0 1 1 49
05 000 00 1 0 0 0 0 0 0 00
06 00F 0F 0 0 0 0 0 1 1 51
07 00F 0F 0 0 0 0 0 1 1 59
08 00F 0F 0 0 0 0 0 1 1 61
09 00F 0F 0 0 0 0 0 1 1 69
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 00F 0F 0 0 0 0 0 1 1 71
0d 00F 0F 0 0 0 0 0 1 1 79
0e 00F 0F 0 0 0 0 0 1 1 81
0f 00F 0F 0 0 0 0 0 1 1 89
10 00F 0F 1 1 0 1 0 1 1 91
11 000 00 1 0 0 0 0 0 0 00
12 00F 0F 1 1 0 1 0 1 1 99
13 00F 0F 1 1 0 1 0 1 1 A1
14 000 00 1 0 0 0 0 0 0 00
15 00F 0F 1 1 0 1 0 1 1 A9
16 00F 0F 1 1 0 1 0 1 1 B1
17 000 00 1 0 0 0 0 0 0 00
IO APIC #3......
.... register #00: 03000000
....... : physical APIC id: 03
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 03000000
....... : arbitration: 03
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 000 00 1 0 0 0 0 0 0 00
07 000 00 1 0 0 0 0 0 0 00
08 00F 0F 1 1 0 1 0 1 1 B9
09 00F 0F 1 1 0 1 0 1 1 C1
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IO APIC #4......
.... register #00: 04000000
....... : physical APIC id: 04
.... register #01: 00178020
....... : max redirection entries: 0017
....... : PRQ implemented: 1
....... : IO APIC version: 0020
.... register #02: 04000000
....... : arbitration: 04
.... IRQ redirection table:
NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect:
00 000 00 1 0 0 0 0 0 0 00
01 000 00 1 0 0 0 0 0 0 00
02 000 00 1 0 0 0 0 0 0 00
03 000 00 1 0 0 0 0 0 0 00
04 000 00 1 0 0 0 0 0 0 00
05 000 00 1 0 0 0 0 0 0 00
06 00F 0F 1 1 0 1 0 1 1 C9
07 000 00 1 0 0 0 0 0 0 00
08 000 00 1 0 0 0 0 0 0 00
09 000 00 1 0 0 0 0 0 0 00
0a 000 00 1 0 0 0 0 0 0 00
0b 000 00 1 0 0 0 0 0 0 00
0c 000 00 1 0 0 0 0 0 0 00
0d 000 00 1 0 0 0 0 0 0 00
0e 000 00 1 0 0 0 0 0 0 00
0f 000 00 1 0 0 0 0 0 0 00
10 000 00 1 0 0 0 0 0 0 00
11 000 00 1 0 0 0 0 0 0 00
12 000 00 1 0 0 0 0 0 0 00
13 000 00 1 0 0 0 0 0 0 00
14 000 00 1 0 0 0 0 0 0 00
15 000 00 1 0 0 0 0 0 0 00
16 000 00 1 0 0 0 0 0 0 00
17 000 00 1 0 0 0 0 0 0 00
IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 0:16
IRQ18 -> 0:18
IRQ19 -> 0:19
IRQ21 -> 0:21
IRQ22 -> 0:22
IRQ32 -> 1:8
IRQ33 -> 1:9
IRQ54 -> 2:6
.................................... done.
Using local APIC timer interrupts.
calibrating APIC timer ...
..... CPU clock speed is 2395.0977 MHz.
..... host bus clock speed is 99.1586 MHz.
cpu: 0, clocks: 194933, slice: 38986
CPU0<T0:194928,T1:155936,D:6,S:38986,C:194933>
cpu: 1, clocks: 194933, slice: 38986
cpu: 3, clocks: 194933, slice: 38986
cpu: 2, clocks: 194933, slice: 38986
CPU1<T0:194928,T1:116944,D:12,S:38986,C:194933>
CPU2<T0:194928,T1:77968,D:2,S:38986,C:194933>
CPU3<T0:194928,T1:38976,D:8,S:38986,C:194933>
checking TSC synchronization across CPUs: passed.
migration_task 0 on cpu=0
migration_task 1 on cpu=1
migration_task 2 on cpu=2
migration_task 3 on cpu=3
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
PCI: PCI BIOS revision 2.10 entry at 0xfd8b5, last bus=4
PCI: Using configuration type 1
PCI: Probing PCI hardware
Transparent bridge - Intel Corp. 82801BA/CA/DB PCI Bridge
PCI: Discovered primary peer bus 10 [IRQ]
PCI: Discovered primary peer bus 11 [IRQ]
PCI: Discovered primary peer bus 12 [IRQ]
PCI: Using IRQ router PIIX [8086/2480] at 00:1f.0
PCI->APIC IRQ transform: (B0,I29,P0) -> 16
PCI->APIC IRQ transform: (B0,I29,P1) -> 19
PCI->APIC IRQ transform: (B0,I29,P2) -> 18
PCI->APIC IRQ transform: (B2,I3,P0) -> 54
PCI->APIC IRQ transform: (B3,I2,P0) -> 32
PCI->APIC IRQ transform: (B3,I2,P1) -> 33
PCI->APIC IRQ transform: (B4,I4,P0) -> 21
PCI->APIC IRQ transform: (B4,I5,P0) -> 22
^ permalink raw reply
* Re: Undelete files on ext3 ??
From: Jan Hudec @ 2003-01-08 8:00 UTC (permalink / raw)
To: Gerhard Mack
Cc: Andreas Dilger, Richard B. Johnson, Max Valdez, Jan Hudec, kernel
In-Reply-To: <Pine.LNX.4.44.0301080000250.18804-100000@innerfire.net>
On Wed, Jan 08, 2003 at 12:01:34AM -0500, Gerhard Mack wrote:
> On Tue, 7 Jan 2003, Andreas Dilger wrote:
>
> > Date: Tue, 7 Jan 2003 11:55:44 -0700
> > From: Andreas Dilger <adilger@clusterfs.com>
> > To: Richard B. Johnson <root@chaos.analogic.com>
> > Cc: Max Valdez <maxvaldez@yahoo.com>, Jan Hudec <bulb@ucw.cz>,
> > kernel <linux-kernel@vger.kernel.org>
> > Subject: Re: Undelete files on ext3 ??
> >
> > On Jan 07, 2003 13:17 -0500, Richard B. Johnson wrote:
> > > Therefore, it's time for somebody to put a 'dumpster` in all the Linux
> > > file-systems. Somebody should then modify `rm` and the kernel unlink
> > > to `mv' files to the dumpster directory on the file-system, instead of
> > > really deleting them. Then, just like the Redmond stuff, a separate
> > > program can be used to clear out the "dumpster" or `mv` them back.
> >
> > This is very FAQ. Please see the l-k archives for any year to find
> > lengthy discussions about this.
> >
>
> Funny my gnome2 install has a wastebasket and last I checked if you open a
> command shell in windows and del *.* you are screwed anyhow.
>
> So we have exactly the same functionality windows does.
Yes. But we could do better. Since no program uses the __syscall
interface directly, wraping unlink in libc would affect all programs
including rm. It could even be done withou recompiling anything using
LD_PRELOAD.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* small fix for nforce ide chipset driver in 2.5.54
From: James Curbo @ 2003-01-08 7:55 UTC (permalink / raw)
To: andre; +Cc: linux-kernel
I recently acquired an Epox 8RDA motherboard, which uses the Nforce2
chipset. While trying to compile 2.5.54 I ran across an error in
drivers/ide/pci/nvidia.c. Several times the define
PCI_DEVICE_ID_NVIDIA_NFORCE_IDE is referenced, but is not defined
anywhere. It seems it is missing from include/linux/pci_ids.h. On my
board it shows up as:
00:09.0 IDE interface: nVidia Corporation: Unknown device 0065 (rev a2)
(prog-if 8a [Master SecP PriP])
so I added a #define for PCI_DEVICE_ID_NVIDIA_NFORCE_IDE as 0x0065. It
compiled fine and I am in fact running that kernel now. I would have
just sent a patch but I am new to kernel hacking, this is just a one
liner and I'm sure you know where it goes better than I do.
thanks, James
--
James Curbo <hannibal@adtrw.org> <phoenix@sandwich.net>
^ permalink raw reply
* Re: Nvidia and its choice to read the GPL "differently"
From: Richard Stallman @ 2003-01-08 8:00 UTC (permalink / raw)
To: lm; +Cc: lm, acahalan, linux-kernel
In-Reply-To: <20030107142612.GO17602@work.bitmover.com>
Great. So not only is there no legal need to cite GNU in the Linux
name, there is no ethical obligation either.
When you take part of my statement, stretch it, interpret it based on
assumptions you know I disagree with, and present the result as
something I said, that doesn't prove anything. It is childish.
There is no ethical obligation to mention secondary contributions
incorporated in a large project. There ethical obligation is to cite
the main developer. In the GNU/Linux system, the GNU Project is the
principal contributor; the system is more GNU than anything else,
and we started it.
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Richard Stallman @ 2003-01-08 8:00 UTC (permalink / raw)
To: billh; +Cc: mark, lm, linux-kernel, paul, riel, billh
In-Reply-To: <20030107141758.GA10770@gnuppy.monkey.org>
It's not Hurd that I'm criticizing as much as the over emphasis on any single
ideological entity and the amorphous definition of GNU in multipule
contexts, social, technological, etc...
The definition of GNU is simple: GNU is an operating system. In 1983
I announced the plan to develop a Unix-like operating system that
would be entirely free software, and I gave the system the name GNU.
>From this concept come other derived concepts. For instance,
developing the system is a project. That's the GNU Project. Carrying
out such a project involves writing lots of programs. Programs that
have been developed for GNU or contributed by their developers
specifically to GNU are called GNU programs, GNU packages, or
collectively GNU software. (Those three terms are equivalent.) The
manuals developed for GNU or contributed specifically to GNU are GNU
manuals.
We wrote some licenses to use on GNU programs and manuals.
These are the GNU licenses.
GNU is also associated with a movement and a philosophy, but we don't
call them "GNU". We call them the Free Software Movement, and its
philosophy. Nonetheless, the main place people come across them is in
connection with GNU, and the success of the GNU Project is the best
way to refute the common presupposition that idealism like ours is
impractical. So we want people to know of the system as GNU.
We're looking for a good term to use for "programs released under GNU
licenses", because we want to educate the community that this is not
the same thing as free software (there are other free software
licenses) and not the same thing as GNU software (releasing a program
under a GNU license does not imply that you did it as part of the GNU
Project, as witness for example Linux). If you have a suggestion, and
a few of your friends like it, please email it to me.
Richard Stallman
Chief GNUisance
^ permalink raw reply
* Re: Why is Nvidia given GPL'd code to use in closed source drivers?
From: Richard Stallman @ 2003-01-08 8:00 UTC (permalink / raw)
To: billh; +Cc: mark, lm, linux-kernel, paul, riel, billh
In-Reply-To: <20030107141758.GA10770@gnuppy.monkey.org>
activistic political structure to bind a project like this, but
the successful execution of Linux as a large scale political,
social and economic product (credit to folks like Linus, Alan Cox,
Stephen Tweedie, etc...)
When you say "Linux" here, do you mean the kernel, or the whole
GNU/Linux system? With all due respect, I think you may not have
answered this question for yourself, because the people that you name
are people who worked on the kernel, but the success that you talk
about is the success of the whole system. (No kernel alone could have
had this effect.)
The practice of referring to the whole system by the same name as the
kernel alone leads to constant confusion between the two. You will
often see statements that "Linux is a Unix-like operating system, like
Solaris or FreeBSD, which is released under the GNU GPL." That is
false regardless of what meaning you assign to "Linux". The only way
to avoid confusion is to stop calling the whole system by the name
used for the kernel.
really paved the way for the entire open
source community as we understand it.
Our community is the free software community; it was built by the
idealism of the free software movement.
Like any community, it contains people with different views. Nowadays
many of the people in our community support the open source movement.
The open source advocates are legitimate members of the community, and
some have contributed to it. They have a right to form a movement to
promote their views, but that movement was started only in 1998, long
after the community existed. Their movement did not build the
community, and it should not be named after them.
Speaking of which, your ideas seem to have a lot in common with the
free software movement. I wonder if you thought that the open source
movement was the only one and that we all support it. (Many
inaccurate articles give that impression.) If you read about the free
software movement, you might decide we are closer to your views.
See http://www.gnu.org/philosophy/, and in particular
http://www.gnu.org/philosophy/free-software-for-freedom.html for an
explanation of the difference between the two movements. We and they
have similar practices, which is why we and they can work together
some of the time, but what we say about it is very different from
what they say.
^ permalink raw reply
* Re: Re: /var/lib/nfs/sm/ files
From: David Shirley @ 2003-01-08 8:08 UTC (permalink / raw)
To: Christian Reis, Trond Myklebust; +Cc: NFS
In-Reply-To: <shsn0mcj3x8.fsf@charged.uio.no>
Trond,
Will the client automatically remount or fix the mount
once the server comes back up? ie after the server
notifys the client, or does the client still have to restart
nfs?
Cheers
Dave
----- Original Message -----
From: "Trond Myklebust" <trond.myklebust@fys.uio.no>
To: "Christian Reis" <kiko@async.com.br>
Cc: <NFS@lists.sourceforge.net>; <linux-kernel@vger.kernel.org>
Sent: Wednesday, January 08, 2003 12:54 AM
Subject: [NFS] Re: /var/lib/nfs/sm/ files
> >>>>> " " == Christian Reis <kiko@async.com.br> writes:
>
> > Hi there,
>
> > Can `anybody' (Neil, Trond?) explain what the entries in
> > /var/lib/nfs/sm/ are for? If they refer to file locks, can we
>
> 'man rpc.statd'. Those files store the IP-addresses of the machines
> being monitored by statd. In case of a crash or a reboot, those files
> tell statd which machines that need to be notified.
>
> Cheers,
> Trond
>
>
> -------------------------------------------------------
> 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
>
-------------------------------------------------------
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
* [Linux-ia64] [RFC] proposed change for syscall stub
From: David Mosberger @ 2003-01-08 8:13 UTC (permalink / raw)
To: linux-ia64
Given all the work that has gone into glibc to support "lightweight"
kernel-entry on x86 linux, I think the time is ripe to setup things
for ia64 as well. There are many approaches that we can take to
implement faster system calls in the ia64 kernel but the good news is
that with a few simple changes to glibc, we gain the ability to
support pretty much _any_ approach. The basic idea is as follows:
The old system call stub looks like this:
old_syscall:
mov r15 = SYSCALL_NR
break 0x100000;;
cmp.eq p6,p0 = -1, r10
(p6) br.cond.spnt.few syscall_error
br.ret.sptk rp
we can replace this by:
new_syscall_stub:
adds r2 = SYSINFO_OFF, r13;;
ld8 r2 = [r2]
mov r9 = ar.pfs;;
mov b6 = r2
mov r15 = SYSCALL_NR;;
br.call.sptk.many b6¶;;
cmp.eq p6,p0 = -1, r10
mov ar.pfs = r9
(p6) br.cond.spnt.few syscall_error
br.ret.sptk.many rp
Here, SYSINFO_OFF is the offset in the user-level thread-control-block
at which the system call entry point is stored. glibc initializes
this value to point to the following piece of code:
default_syscall:
break 0x100000
br.ret.sptk.many b6
The new setup causes syscall stubs to be somewhat bigger (4 bundles
instead of 2 bundles). Also, due to the indirection, you'd think that
execution time also is slightly slower, though in practice the
difference is quite small (in fact, for the getpid() test case I used,
the test program reported 349 cycles for the new stub and 351 cycles
for the old one; go figure...).
On the upside, we gain a lot of flexibility: new kernels can override
the syscall entry point in the user-level thread-control-block via the
AT_SYSINFO ELF auxiliary table entry. For example, this would allow
us to implement light-weight system calls via "epc". I did a quick &
dirty proof-of-concept and something trivial like getpid, we should be
able to do in well less than 100 cycles (while maintaining full system
call compatibility, including for stuff like signal-delivery checking
and strace'ing).
Now why does the new syscall stub look the way it does? The goal I
had was to make the new syscall stub a "drop-in" replacement for the
old code sequence. In particular, I wanted to retain the ability to
do a system call without having to copy around argument registers. To
make this work, we need to be able to preserve "rp" (b0) and the
contents of ar.pfs without allocating local registers. For this
reason, the new syscall stub uses a non-standard calling sequence
which requires registers r9 and rp to be preserved. Other than that,
the stub probably looks like you'd expect. Fortunately, since the old
kernels preserves these registers anyhow, we should be fine here.
Anyhow, I'd be interested in comments & feedback. My hope is that we
could make the glibc changes relatively soon, as that would enable
kernel experimentation without affecting user-level in any fashion.
--david
^ permalink raw reply
* Re: Seagate Cheetah: Firmware, Bugs, Compatibility?
From: Shanker Balan @ 2003-01-08 8:15 UTC (permalink / raw)
To: Linux-SCSI
In-Reply-To: <Pine.LNX.4.44.0301072238580.3021-100000@uplift.swm.pp.se>
Hello:
Mikael Abrahamsson wrote,
> If I have not had any of my problems in 2-3 weeks I'll email back it
> as a success report.
I am having problems flashing the drive. I get an "-2" error with
sgdskfl.
Error -2 is a "-2 means that the SCSI request returned a check condition
(sense error)" from the UserGuide.
I got a similar sense error while trying to flash using the Quantum supplied
"DL_scsi.exe" under DOS.
Andrew, any idea what might be the problem here? Also whats a "Servo
image"?
Here is paste from "sgdskfl" run:
Log file /var/log/sgdskfl.log is open, debug=0
Num Name [bus:ch:id:lun] Type Vendor Device_Model FW__ Serial#_
Servo___
0 /dev/sg0 [0:0:0:0] Disk QUANTUM ATLAS10K3_18_SCA 020W 34220894
1 /dev/sg1 [0:0:1:0] Disk QUANTUM ATLAS10K3_73_SCA 020W 34820965
2 /dev/sg2 [0:0:2:0] Disk QUANTUM ATLAS10K3_73_SCA 020W 34820635
Enter Selection ('d' to download, 'q' to quit) : d
Device Num (0 to 2) : 2
Selected 2: [0:2] QUANTUM ATLAS10K3_73_SCA020W34820635
Reading image file atlas10k.lod, size = 377167
No servo image
Device [2] is ready for download
Starting download process for 1 disk.
Downloading Firmware image to disk 2 Wed Jan 8 13:40:52 2003
Current sg_cmd_done_bh00:00: sense key Illegal Request
write_buffer: Check Condition Driver_status=0x08 (DRIVER_SENSE,SUGGEST_OK)
sense error, key=05 asc=26 ascq=80 Illegal RequestInfo valid=0, Current
[2] Error -2 in writing buffer
Press ENTER to continue
-- Shanu
http://shankerbalan.com/
^ permalink raw reply
* Re: OT: curious about eth0/eth1
From: Arnt Karlsen @ 2003-01-08 8:21 UTC (permalink / raw)
To: netfilter
In-Reply-To: <200301072247.24369.netfilter@newkirk.us>
On Tue, 7 Jan 2003 22:47:24 -0500,
Joel Newkirk <netfilter@newkirk.us> wrote in message
<200301072247.24369.netfilter@newkirk.us>:
> On Tuesday 07 January 2003 06:59 pm, Tommy McNeely wrote:
> > I am curious about why people choose to make a certain interface
> > internal or external...
>
> > I notice several people pick eth0 as their outside interface, and
> > sorta "oh yea" the rest of the inside network is on eth1. I know
> > the linux kernel could really care less what they are called, its
> > mostly a"neatness" thing I guess... Also it seems like that leaves
> > your box open to attack from the time it installs (if you do a NET
> > based install) till the time you get around to actually putting a
> > firewall on it.
>
> Why would this in particular leave a box exposed?
>
> I think that the main reason for 'some one way, some the other' is
> random chance. However, consider this scenario:
>
> You have two NICs, eth0 and eth1. The connections on one you trust (-i
>
> eth0 -j ACCEPT), the other you don't. One of them fails, or the board
>
> works loose from it's socket, or something, so that upon booting the
> machine you only have one interface. No matter which board fails, the
>
> remaining board would be eth0. If eth0 is your 'trusted' internal
> network in normal conditions, and it fails, then suddenly the
> untrusted network is operating under the trusted network's rules.
> However, the IP assignment (if static!) would remain that of the
> trusted network, so as long as eth0 is configured with a static IP
> this shouldn't present a risk. If, however, both are dynamic, (say
> DHCP assigned) then this would qualify as a security hole, possibly a
> huge one. To be fair, this is probably a very rare intersection of
> situations, but if eth0 is the untrusted network, then any failure
> would be an annoyance, not a risk.
..in a hobbyist environment, agreed. In business, you want to minimize
the impact of such failures, the easiest way is to use the hardware
addresses to ID your nics, if one fails, only it fails, without leaving
the entire box open for outsiders on the "now trusted" nic. ;-)
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
^ permalink raw reply
* [LARTC] Problems with the HTB cue
From: Jesper Kold-Hansen @ 2003-01-08 8:30 UTC (permalink / raw)
To: lartc
I have a problem. As soon I patch my kernel with HTB, or recompile with a
kernel with the HTB cue included, I start getting problems. When ever I
try to make a connection to another computer, I get connection refused.
That goes for all services. I have tryed FTP HTTP TELNET. All atempts to
make a connection gives a connection refused.
But there is a additional thing. If I set up iptables, and a bandwtith
trottle script on the server, everybody behind the linux routere, have no
problem getting on the internet. So say it short on the linux router with
HTB i get connection refused, but every one who rutes thrue the linux
router have no problems.
Oh yah one last thing, I did this on a 2.4.18 kernel that I patched with
the HTB cue. And the only thing I changed in the make config, was to
include the HTB cue in the kernel, and there were no problems before the
patch.
Hope someone has an anserw.
CandyMan.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply
* Re: Redhat 8.0 with Iptables and Cisco 2514
From: Joel Newkirk @ 2003-01-08 8:31 UTC (permalink / raw)
To: JUSTIN GERRY, netfilter
In-Reply-To: <se1b0154.064@butchers.com>
On Tuesday 07 January 2003 04:32 pm, JUSTIN GERRY wrote:
> Trying to figure out why, when I enable the firewall on my cisco
> (which is a state checking firewall) and I have my iptables (also
> state checking) firewall enabled on my redhat box I can not establish
> a connection with with my website (either website one as I have two
> interfaces and I am using apache to host both)
>
> It almost seems as if the cisco is destroying the incoming connection
> (probably the outgoing response because I can see people connecting to
> my box) before my box has a chance to send out a response.
>
> If I run no firewall on my redhat box and leave the firewall up on my
> cisco then you can access my website normally.
What about the reverse? If the cisco's firewalling is disabled, but
iptables in use, can you connect?
> If anyone has had this problem please let me know.
>
> FYI, my simple firewall test:
>
> F1="eth0"
> IF2="eth1"
> IP2="xxx" #(real ip address hidden)
> IP1="xxx" #(real ip address hidden)
> UNPRIVPORTS="1024:65535"
>
> iptables -F
> iptables -P INPUT DROP
> iptables -P FORWARD DROP
> iptables -P OUTPUT DROP
>
> iptables -A INPUT -p tcp --sport $UNPRIVPORTS \
> --dport 80 -m state --state NEW -j ACCEPT
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
If the answer above is "it works", then what if you loosen the NEW rule
in INPUT? Try:
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
with the cisco's firewall enabled. If this fails, I suspect the cisco's
configuration is blocking outbound replies, so you'd have to dig there.
A quick test with logging in INPUT and OUTPUT chains would tell you if
the request is actually reaching your machine, and being responded to
properly. Just add a log rule at the start and the end of each of those
two chains, with distinct '--log-prefix' strings, and make sure you log
from the first and ONLY the first one in each chain. The first log
tells you it hits the chain, the second that it hits the DROP policy.
j
> Many thanks,
> Justin
^ permalink raw reply
* Re: ACPI on the Compaq Presario 735CA
From: Adrian Turcu @ 2003-01-08 8:33 UTC (permalink / raw)
To: Sergiomb-5ng0By4jB+/QUPosyRRdSA
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <1041970142.3e1b33dee22d8@webmail.sapo.pt>
Hi,
I think I forgot this in my page :) I have it already and is working great.
Thanks for the tip,
Adi
Sérgio Monteiro Basto wrote:
>Hi I read your page and it is great I done my page too
>for compaq pressario 706EA, you should aplly also new
>s3savage drive.
>
>see it in:
>http://codecs.home.sapo.pt/
>
>
>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
^ permalink raw reply
* [linux-lvm] LVM Recovery (urgent)
From: Andre Bonhote @ 2003-01-08 8:34 UTC (permalink / raw)
To: Linux-LVM, Mauelshagen; +Cc: beat
Hi Heinz
Since I was not sure if you really understand the german tongue, so I write
in english. You're really kind of my last resort concerning my problem.
You might ask why I don't write to one of the mailing lists. Well, the
answer is quite simple: I don't trust them in this case. I don't think I
have many tries left to save my data, so I need a real expert advice. Don't
ask about a backup, there's none. And this is just one of my major faults.
But maybe I found a bug, we'll see. Let me describe my problem and what I
did first.
My setup is as following:
- 2 SCSI drives, 18/9 GB
- 1 IDE drive, 80 GB
- Redhat 8.0, with
- / on LVM (!! Redhat allows this without warning. I didn't know about
the
dangerosity)
- /boot on a standard ext3 partition
- /home, respectively /new-home on LVM, which is my major concern.
- I have/had one VG, /dev/CaradhrasVG/ spanning first the two SCSI disks.
Yesterday I added the IDE disk to this VG.
- /dev/CaradhrasVG/RootVG holding the /(remember this name!). Here, also
/new-home and /home is located
- /dev/CaradhrasVG/HomeLV, formatted with ext3 but empty. It was intended
to
copy the homes here lateron.
Fdisk shows this:
/dev/sda:
255 heads, 63 sectors, 1106 cyls
/dev/sda1,Bootable,Start:1,End:13,Blocks:104391,83/Linux
/dev/sda2,-,Start:14,End:1106,Blocks:8779522+,8e/LinuxLVM
/dev/sdb
2231 cyls
/dev/sdb1,Bootable,Start:1,End:2231,Blocks:17920476,8e/LinuxLVM
/dev/hdc
fdisk -l shows no output. There's no partitioning. I did pvcreate /dev/hdc.
Ok, yesternight I added my IDE drive /dev/hdc to the VG. With the new space
inside the VG I decided to create the HomeLV using the whole new space.
Doing this (which ran fine and without any hassle), I found that the Root
Volume had the wrong name (RootVG instead of RootLV). So I changed its name
using "lvrename". After that, I changed the entry in /etc/fstab. First big
mistake. The result was, that no booting was possible with an error message
like that:
mount: error 2 mounting ext3
pivotroot: pivot_root(/sysroot,/sysroot/initrd) failed: 2
umount /initrd/proc failed: 2
A search on google brought exactly two japanese pages. A different search
showed up a lot of different error codes, but not "error 2".
Since Redhat offers the "linux rescue" mode on their CD, I tried that, and
voil�! it worked. But here, I obviously did my second (but less serious
IMHO) mistake. Without being in a chrooted environment, I changed the name
of RootLV back to RootVG. After booting from disk, my RH installation booted
and found init but failed to fsck /. Simply because the Volume was still
somehow named RootVG, but mounted as RootLV.
Then all went very fast. It was almost three o'clock in the morning and I
was very tired and angry about myself, this is obviously one of the reasons
why I commited such stupid, stupid mistakes. But here we go.
I decided to extract the (unused? no!) IDE drive from the VG to store the
important data in some safe place. Again, with RH's rescue CD but WITHOUT
chroot. When I issued "vgreduce CaradhrasVG /dev/hdc", vgreduce answered
with an error message like "it's in use. don't do that". Well, I thought in
my fever that it means the VG which was in use. Therefore I rebooted with
the CD but I didn't mount the OS on the disks at all, which I thought would
allow me to vgreduce. It worked, but with an error message which I don't
remember. I personally think that the label on /dev/hdc has been removed but
no (which?) config files have been updated. Could this be a bug? Well,
anyway, after a reboot with the RH CD there was just the message "Could not
find a valid RedHat Installation". Bang-boom. "vgscan -v" shows this:
...
reading data of volume group "CaradhrasVG" from physical volume(s)
ERROR "vg_read_with_pv_and_lv(): current PV" can't get data of volume group
"CaradhrasVG" from physical volumes
...
For me, this shows that if /dev/hdc would be added to the VG again, it could
work.
You know, I don't care about my personal data. But on these disks, we have
around 3100 pictures of our kids of which I don't have a solid backup (some
months are missing), and all my wife's E-Mails (which was just too big to
store on a CD Rom) plus some very, very old compuserve mails which document
how my wife and I met several years ago. It's memory, without backup. That's
also why I don't trust the mailing lists: It's just too important to me and
my wife! I hope you understand that and accept it as a reason why I am
bothering you personally.
I don't know the LVM internals, but I have several ideas how I could bring
the data back. I am kindly asking you to point out IF there's a way to fix
it, and if yes, how I could do it. Here's what I was thinking of.
- I could try (under your lead if possible) to bring /dev/hdc back into the
CaradhrasVG
so that I can redo what I wanted to (extract hdc), but CLEANLY this time.
IMHO this is
the safest solution, if it's possible. As I said, I don't know how LVM
rally works,
but I guess that you store information about the VG membership somewhere
on the drive
itself. If yes, there could be a chance to recover that (hopefully).
- The second approach (which I don't like that much) is to remove the hdc
from the VG
somehow. But since I don't have access to /etc, I have no clue how to
manage this.
- The third possible approach (which I really don't like) is to try to
access /home and
/new-home on the VG directly somehow. I am quite sure that only the SCSI
disks are used
by the VG, but not 100%
This mail will go in CC to Beat Rubischon, a veteran unix admin and head of
the LUGS. He agreed to help me sorting out this mess.
Heinz, I really hope you feel my desesperation. I have no clue how to
proceed best from here, but I also don't want to accept that all data is
lost. It's just too emotionally important to us. Memories.
Thank you very much in advance. I am really looking forward to hearing from
you soon, and if it's only a line like "yes, I have read your mail and I am
thinking about it" or something similar. This would set me a bit at ease.
Yours Sincerely
Andr� Bonhote
--
Andre Bonhote - Foehrenweg 6 - CH-8956 Killwangen
P: +41564011734 M: +41797069322 F: +41564011712
Pers: andre@bonhote.com Bus:andre.bonhote@colt.ch
^ permalink raw reply
* Re: Fwd: Patch for initial CapsLock
From: Vojtech Pavlik @ 2003-01-08 8:45 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: Vojtech Pavlik, linux-kernel
In-Reply-To: <20030107170746.A2689@devserv.devel.redhat.com>
On Tue, Jan 07, 2003 at 05:07:46PM -0500, Pete Zaitcev wrote:
> > > Do you want me to do the same for 2.5? It should be a little
> > > simpler there, and no new exports.
> >
> > Yes, please.
>
> Done, works for me.
>
> I toyed with the idea to trigger keyboard tasklet instead of
> locking it out and calling methods, but I did not see how
> to force updates for unchanged ledstate. Changing ledstate to 0xff
> just looked so very wrong...
Thanks, this looks very good.
>
> -- Pete
>
> --- linux-2.5.54/drivers/char/keyboard.c 2002-12-15 18:07:54.000000000 -0800
> +++ linux-2.5.54-p3/drivers/char/keyboard.c 2003-01-07 13:55:25.000000000 -0800
> @@ -894,9 +894,9 @@
> * Aside from timing (which isn't really that important for
> * keyboard interrupts as they happen often), using the software
> * interrupt routines for this thing allows us to easily mask
> - * this when we don't want any of the above to happen. Not yet
> - * used, but this allows for easy and efficient race-condition
> - * prevention later on.
> + * this when we don't want any of the above to happen.
> + * This allows for easy and efficient race-condition prevention
> + * for kbd_refresh_leds => input_event(dev, EV_LED, ...) => ...
> */
>
> static void kbd_bh(unsigned long dummy)
> @@ -918,6 +918,22 @@
>
> DECLARE_TASKLET_DISABLED(keyboard_tasklet, kbd_bh, 0);
>
> +/*
> + * This allows a newly plugged keyboard to pick the LED state.
> + */
> +void kbd_refresh_leds(struct input_handle *handle)
> +{
> + unsigned char leds = ledstate;
> +
> + tasklet_disable(&keyboard_tasklet);
> + if (leds != 0xff) {
> + input_event(handle->dev, EV_LED, LED_SCROLLL, !!(leds & 0x01));
> + input_event(handle->dev, EV_LED, LED_NUML, !!(leds & 0x02));
> + input_event(handle->dev, EV_LED, LED_CAPSL, !!(leds & 0x04));
> + }
> + tasklet_enable(&keyboard_tasklet);
> +}
> +
> #if defined(CONFIG_X86) || defined(CONFIG_IA64) || defined(CONFIG_ALPHA) || defined(CONFIG_MIPS) || defined(CONFIG_PPC) || defined(CONFIG_SPARC32) || defined(CONFIG_SPARC64)
>
> static unsigned short x86_keycodes[256] =
> @@ -1159,6 +1175,7 @@
> handle->name = kbd_name;
>
> input_open_device(handle);
> + kbd_refresh_leds(handle);
>
> return handle;
> }
--
Vojtech Pavlik
SuSE Labs
^ permalink raw reply
* Re: [2.5.54-dj1-bk] Some interesting experiences...
From: Vojtech Pavlik @ 2003-01-08 8:52 UTC (permalink / raw)
To: Anders Gustafsson; +Cc: Joshua Kwan, linux-kernel, vojtech
In-Reply-To: <20030108015107.GA2170@gagarin>
On Wed, Jan 08, 2003 at 02:51:07AM +0100, Anders Gustafsson wrote:
> On Tue, Jan 07, 2003 at 05:21:46PM -0800, Joshua Kwan wrote:
> >
> > 3. [linux-2.5] PS/2 mouse goes haywire every 30 seconds or so of use.
> > dmesg sayeth:
> > mice: PS/2 mouse device common for all mice
> > input: PS/2 Synaptics TouchPad on isa0060/serio4
> >
> > but more importantly this is the cause:
> >
> > psmouse.c: Lost synchronization, throwing 2 bytes away.
> > psmouse.c: Lost synchronization, throwing 2 bytes away.
>
> This happens here too. But not that frequent at all, more like once every
> hour. And has happend on all kernels since at least 2.5.46 [1].
>
> However 5 hours ago I changed the timeout in psmouse.c from 50ms to 100ms.
> And now it haven't misbehaved yet, but that might be just some nightly luck.
> Is there something that turns off interupts or something and hinders the
> mouse driver from processing the data for such long time? Or is my hardware
> just buggy?
That I'd like to know, too. In the worst case, we can make the timeout
be half a second, or more - it'd just mean that for a resync you would
have to not touch the mouse this long if really a byte is lost.
> [1] http://marc.theaimsgroup.com/?l=linux-kernel&m=103688231622278&w=2
>
> --
> Anders Gustafsson - andersg@0x63.nu - http://0x63.nu/
--
Vojtech Pavlik
SuSE Labs
^ 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.