* Re: "bio too big" error
From: Kevin Corry @ 2002-12-12 21:51 UTC (permalink / raw)
To: Joe Thornber, Wil Reichert; +Cc: Greg KH, kernel list, lvm-devel
In-Reply-To: <20021212091209.GA1299@reti>
On Thursday 12 December 2002 03:12, Joe Thornber wrote:
> On Wed, Dec 11, 2002 at 04:15:42PM -0800, Wil Reichert wrote:
> > Ok, 2.5.51 plus dm patches result in the following:
> >
> > Initializing LVM: device-mapper: device
> > /dev/ide/host2/bus1/target0/lun0/disc too small for target
> > device-mapper: internal error adding target to table
> > device-mapper: destroying table
> > device-mapper ioctl cmd 2 failed: Invalid argument
> > Couldn't load device 'cheese_vg-blah'.
> > 0 logical volume(s) in volume group "cheese_vg" now active
> > lvm2.
> >
> > Was fine (minus of course the entire bio thing) in 50, did something
> > break in 51 or is it just my box?
>
> I've had a couple of reports of this problem. The offending patch is:
>
> http://people.sistina.com/~thornber/patches/2.5-stable/2.5.51/2.5.51-dm-1/0
>0005.patch
>
> back it out if necc.
>
> All it does is:
>
> --- diff/drivers/md/dm-table.c 2002-12-11 11:59:51.000000000 +0000
> +++ source/drivers/md/dm-table.c 2002-12-11 12:00:00.000000000 +0000
> @@ -388,7 +388,7 @@
> static int check_device_area(struct dm_dev *dd, sector_t start, sector_t
> len) {
> sector_t dev_size;
> - dev_size = dd->bdev->bd_inode->i_size;
> + dev_size = dd->bdev->bd_inode->i_size >> SECTOR_SHIFT;
> return ((start < dev_size) && (len <= (dev_size - start)));
> }
Actually, this 00005.patch *is* necessary. dd->bdev->bd_inode->i_size *is* in
bytes, and does need to be shifted to do the above comparison.
I believe we have tracked the problem down to the call to dm_get_device() in
dm-linear.c. It is passing in an incorrect value, which winds up being the
"start" parameter to the check_device_area() function. I've included a patch
at the end of this email which I believe should fix the problem. I have also
checked dm-stripe.c, and it appears to make the call to dm_get_device()
correctly, so no worries there.
--
Kevin Corry
corryk@us.ibm.com
http://evms.sourceforge.net/
--- linux-2.5.51a/drivers/md/dm-linear.c 2002/11/20 20:09:22 1.1
+++ linux-2.5.51b/drivers/md/dm-linear.c 2002/12/12 21:38:32
@@ -43,7 +43,7 @@
goto bad;
}
- if (dm_get_device(ti, argv[0], ti->begin, ti->len,
+ if (dm_get_device(ti, argv[0], lc->start, ti->len,
dm_table_get_mode(ti->table), &lc->dev)) {
ti->error = "dm-linear: Device lookup failed";
goto bad;
^ permalink raw reply
* Re: 2.5.51 nanosleep fails
From: Jim Houston @ 2002-12-12 22:27 UTC (permalink / raw)
To: Marco d'Itri, julie.n.fleischer, linux-kernel,
Linus Torvalds
Hi Linus, Marco, Julie, Everyone,
It really is broken. I just didn't try enough combinations.
Thanks Julie, the test suite really helps.
The problem is that nanosleep didn't check for the NULL pointer
case and always tries to copy out the remaining time. The attached
patch will fix this problem.
Jim Houston - Concurrent Computer Corp.
--- linux-2.5.51.orig/kernel/timer.c Thu Dec 12 17:08:30 2002
+++ linux-2.5.51.new/kernel/timer.c Thu Dec 12 16:59:10 2002
@@ -1040,7 +1040,7 @@
jiffies_to_timespec(expire, &t);
ret = -ERESTART_RESTARTBLOCK;
- if (copy_to_user(rmtp, &t, sizeof(t)))
+ if (rmtp && copy_to_user(rmtp, &t, sizeof(t)))
ret = -EFAULT;
/* The 'restart' block is already filled in */
}
@@ -1067,7 +1067,7 @@
if (expire) {
struct restart_block *restart;
jiffies_to_timespec(expire, &t);
- if (copy_to_user(rmtp, &t, sizeof(t)))
+ if (rmtp && copy_to_user(rmtp, &t, sizeof(t)))
return -EFAULT;
restart = ¤t_thread_info()->restart_block;
^ permalink raw reply
* Re: kconfig (gkc) [PATCH]
From: Roman Zippel @ 2002-12-12 22:27 UTC (permalink / raw)
To: Romain Lievin; +Cc: Linux Kernel
In-Reply-To: <20021212212904.GA8103@free.fr>
Hi,
On Thu, 12 Dec 2002, Romain Lievin wrote:
> You will find a patch against 2.5.51 on http://tilp.info/perso/gkc.html.
Is gtk 2.1.4 really required? Debian has only 2.0, I changed the test to
get it compiled and it seems to work anyway.
bye, Roman
^ permalink raw reply
* Re: PROBLEM: PS/2 keyboard and mouse not available/working/weird
From: Take Vos @ 2002-12-12 19:36 UTC (permalink / raw)
To: Vojtech Pavlik; +Cc: Linux Kernel Mailing List
In-Reply-To: <20021022163453.A22665@ucw.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 22 October 2002 16:34, Vojtech Pavlik wrote:
> On Tue, Oct 22, 2002 at 04:03:49PM +0200, Take Vos wrote:
> > In 2.5.44 both my PS/2 mice are not available, neither is my keyboard,
> > although after sufficient keystrokes, sometimes 5, sometimes more, the
> > keyboard is found, this is with Xfree.
I am now using 2.5.51 and I still have the problem when I reboot from a 2.5.51
kernel to a 2.5.51 or 2.4.19 kernel both my internal keyboard and mouse (DELL
Inspiron 8100) are not working anymore. The strange thing is the keyboard
does work in grub.
relevant dmesg output:
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
register interface 'joystick' with class 'input'
register interface 'event' with class 'input'
input: PS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
thanks,
Take Vos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9+OUxMMlizP1UqoURAoXPAKCht3Z/XEo6MIya2gziT6KZ/neDwACfaesk
4ZrzpPHtU280RLRbghmyMnc=
=gTTt
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Intel P6 vs P7 system call performance
From: Zac Hansen @ 2002-12-12 20:12 UTC (permalink / raw)
To: J.A. Magallon; +Cc: linux-kernel
In-Reply-To: <20021212205655.GA1658@werewolf.able.es>
>
> No. The situation is just black. Each day Intel processors are a bigger
> pile of crap and less intelligent
My hyper-threaded xeons beg to argue with you -- all 4 (2) of them.
, but MHz compensate for the average
> office user. Think of what could a P4 do if the same effort put on
> Hz was put on getting cheap a cache of 4Mb or 8Mb like MIPSes have. Or
> closer, 1Mb like G4s.
Err, syscalls are still going to take the same amount of time no matter
how much cache the chip has on it. And, IMHO, adding more cache to make a
processor faster is just as "dumb" as bumping the MHz.
> If syscalls take 300% time but processor is also 300% faster 'nobody
> notices'.
>
The point many are forgetting is that processors do a lot more than system
calls. And P4's are quite quick at doing this.. especially those new
3+GHz ones (with hyperthreading).
By the way, did everyone see the test on Tom's Hardware Guide comparison
between the p4 3.06 with hyperthreading on and a p4 3.6 without
hyperthreading..
http://www17.tomshardware.com/cpu/20021114/index.html
For those of you who just want the info -- here's the spoiler -- when
running multiple apps, the 3.06 can torch the 3.6. Check out the second
benchmark on this page
http://www17.tomshardware.com/cpu/20021114/p4_306ht-16.html
25% faster. Most of the other benchmarks don't show off hyperthreading,
as they're running a single process, but from personal experience, it's
nice. I don't know why they give you the option to turn it off in the
bios. I have 2 xeons, and even then I leave HT on on both. I'd not even
think about considering turning it off if I only had 1 processor..
--Zac
xaxxon@slackworks.com
^ permalink raw reply
* Re: fetchmail and smtp problem
From: Haines Brown @ 2002-12-12 22:14 UTC (permalink / raw)
To: brownh; +Cc: carl, linux-newbie
In-Reply-To: <200212121806.gBCI6P408751@hartford-hwp.com>
I defined the To: field in ~/.fetchmailrc. Here's what I'm using now
for testing
set logfile /opt/tmp/fetchmail_dec12.log
poll pop.registeredsite.com
proto POP3
user brownh@hartford-hwp.com
password XXXX
keep
smtpname brownh@hartford-hwp.com
I now see that I did in fact have emacs set up (setq mail-self-blind
t) all along. For some reason, the blind copies did not show up until
after I had rebooted the HD. But with this new boot, rmail sees them.
I found /var/spool/brownh. Here's what's in it (as I later discovered,
of course, rmail can easily read it).
====================== the failed messages ==========================
1. A message rom Mail Delivery Subsystem
<MAILER-DAEMON@hartford-hwp.com> sent earlier today (when I booted the
present HD? I've not run any mail applications nor gone on line since
yesterday with this HD). The mail deliver subsystem reports that the
address of my message of the day before had a fatal error. Indeed user
localhost@hartford-hwp.com is unknown. But This is a message I sent to
"localhost," and that may simply be impossible.
Here's the critical part:
----- The following addresses had permanent fatal errors -----
localhost
(reason: 550 5.1.1 <localhost@hartford-hwp.com>... User unknown)
(expanded from: localhost)
----- Transcript of session follows -----
... while talking to hartford-hwp.com.:
>>> DATA
<<< 550 5.1.1 <localhost@hartford-hwp.com>... User unknown
550 5.1.1 localhost... User unknown
--gBCJn2fL000871.1039722543/hartford-hwp.com
Content-Type: message/delivery-status
Reporting-MTA: dns; hartford-hwp.com
Arrival-Date: Wed, 11 Dec 2002 18:09:16 -0500
Final-Recipient: RFC822; localhost@hartford-hwp.com
Action: failed
Status: 5.1.1
Remote-MTA: DNS; hartford-hwp.com
Diagnostic-Code: SMTP; 550 5.1.1 <localhost@hartford-hwp.com>... User unknown
Last-Attempt-Date: Thu, 12 Dec 2002 14:49:03 -0500
--gBCJn2fL000871.1039722543/hartford-hwp.com
Content-Type: message/rfc822
Return-Path: <brownh>
Received: (from brownh@localhost)
by hartford-hwp.com (8.12.5/8.12.5/Submit) id gBBN9Gnd002694;
Wed, 11 Dec 2002 18:09:16 -0500
Date: Wed, 11 Dec 2002 18:09:16 -0500
Message-Id: <200212112309.gBBN9Gnd002694@hartford-hwp.com>
From: Haines Brown <brownh@hartford-hwp.com>
To: localhost
Subject: test RH8.0 to localhost dec11 1800
Reply-to: brownh@hartford-hwp.com
2. Also in queue is a message sent to a valid address, which is a mail
fowarding server. The message was not fowarded back to me because the
target name server timed out. This was not a fatal error. I've not
known that I've had trouble with that server. It won't try again until
the 16th.
The header of this message looks ok, except that Return-Path is not a
valid address:
Return-Path: <brownh>
From: Haines Brown <brownh@hartford-hwp.com>
To: kb1grm@arrl.net
Reply-to: brownh@hartford-hwp.com
3. A failed message sent to localhost.localdomain. I don't know that
I'd expect such an address to work, especially since it came out as
localhost.localdomain@hartford-hwp.com.
Would you agree that fetchmail or sendmail is misconfigured? Despite
the provision for blind copy in the mails, I get nothing back right
away. I captured copies of the queue files in case there may be
further useful into in them.
=========================================================================
I compared /etc/aliases, and found that my alias file lacks:
mailer-daemon: postmaster
postmaster: root
But supplies a range of new aliases such as:
sshd: root
smmsp: root
mailman: root
postfix: root
netdump: root
ldap: root
I caputred the /etc/mail/sendmail.cf file, but it's too big and
complicated for ready analysis. There's a lot different from my old
sendmail.cf, but I wouldn't know how to analyse those differences.
I rechecked /ect/hosts:
127.0.0.1 hartford-hwp.com localhost.localdomain localhost
this seems ok
Haines Brown=
-
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: PROBLEM: PS/2 mouse wart does not work, while scratch pad does.
From: Take Vos @ 2002-12-12 19:30 UTC (permalink / raw)
To: Vojtech Pavlik, David Woodhouse; +Cc: linux-kernel, Vojtech Pavlik
In-Reply-To: <20021023104222.B28139@ucw.cz>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 23 October 2002 10:42, Vojtech Pavlik wrote:
> On Wed, Oct 23, 2002 at 12:46:31AM +0100, David Woodhouse wrote:
> > Take.Vos@binary-magic.com said:
> > > hardware:DELL Inspiron 8100
> > >
> > > The internal scratch pad works, but the internal wart mouse doesn't,
> > > in the BIOS it is set to use both devices for input. This is tested
> > > with both Xfree86 and running cat on /dev/input/mice and /dev/input/
> > > mouse0 and /dev/input/event0.
> >
> > Probing for various other PS/2 extensions appears to confuse the thing
> > such that the clitmouse no longer works. If we probe for it first and
> > then abort the other probes, it seems happier...
I just tried 2.5.51, but I still have the same problem, scratch pad works, but
internal wart mouse doesn't.
Here is the current dmesg output:
device class 'input': registering
register interface 'mouse' with class 'input'
mice: PS/2 mouse device common for all mice
register interface 'joystick' with class 'input'
register interface 'event' with class 'input'
input: PS/2 Synaptics TouchPad on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
Thank you,
Take Vos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE9+OPGMMlizP1UqoURAgbUAKCK4JZhpd+nybjJZw2QpXf2wt9lvgCfSzdZ
l7/EHd3rzWVi3bs+iWrUkOY=
=8zyA
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: More progress on loading 2.5.50
From: Hans Reiser @ 2002-12-12 22:21 UTC (permalink / raw)
To: wz6b; +Cc: Linux Kernel Mailing List
In-Reply-To: <200212121351.50151.wz6b@arrl.net>
Matt Young wrote:
>PSAUX is not some fantastic French technology, it must be enabled.
>
;-)
>
>My 3COM/USB adapter seems to be enabled correctly but the LCD lights do not
>blink. Still testing.
>
>95% there, although I did hack into do_mounts and force fed the proper root
>device.
>
>The patch for make that fixes make modules works fine, thank you.
>
>
>Question: Can I turn REISERFS on and off for testing
>
yes, though you'll also need to mkreiserfs your hard drive which has the
pleasing effect of removing and destroying ext2 and all files stored in
it.... (try man mkreiserfs)
> (does in nun on top of
>EXT2)
>
Au contraire, I must say that the ext2 developers are definitely better
nuns than we are.
>
>Yast is a dog.
>-
>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/
>
>
>
>
I think you should use 2.4.20 not 2.5.50. Really, the unstable series
(2.5) is not for people to use, it is for people to test.
^ permalink raw reply
* Re: Alteon AceNIC Coper Seen as Fibre ? (and incorrect settings)
From: Jes Sorensen @ 2002-12-12 22:00 UTC (permalink / raw)
To: Stephan van Hienen; +Cc: sparclinux, linux-kernel
In-Reply-To: <Pine.LNX.4.50.0212102157440.1634-100000@ddx.a2000.nu>
>>>>> "Stephan" == Stephan van Hienen <ultra@a2000.nu> writes:
Stephan> Sun UltraSparc 10 kernel 2.4.20
Stephan> eth2: Alteon AceNIC Gigabit Ethernet at 0x1ff02900000, irq
Stephan> 6,7d0 Tigon II (Rev. 6), Firmware: 12.4.11, MAC:
Stephan> 00:60:cf:20:92:fc PCI bus width: 32 bits, speed: 33MHz,
Stephan> latency: 64 clks eth2: Firmware up and running
Stephan> unplugging the utp cable, and plugging back in gives :
Stephan> eth2: 10/100BaseT link UP eth2: Optical link DOWN eth2:
Stephan> 10/100BaseT link UP
This is purely cosmetic. Basically the firmware sends a link down
event but not media info with it. At the time I wrote the code copper
cards weren't available and I just never got around to changing
it. It's trivial to fix, but really makes no difference whatsoever.
Jes
^ permalink raw reply
* Re: PROBLEM: dvd-drive no longer works (2.4.20)
From: Patrick Petermair @ 2002-12-12 22:05 UTC (permalink / raw)
To: Brendon Higgins, linux-kernel
In-Reply-To: <200212051151.59330.bh_doc@users.sourceforge.net>
Am Donnerstag, 5. Dezember 2002 02:51 schrieb Brendon Higgins:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hello. I have a problem since upgrading linux from 2.4.19 to 2.4.20.
> During boot, the kernel spits out several "status error" and other
> messages about my dvd and cdrw drives (both on ide1).
>
> I upgraded from 2.4.19 to 2.4.20 in the hope that DMA would finally
> work with my vt8235 (MSI KT3 Ultra2 with VIA KT333).
Same here. I also have a MSI KT3 Ultra2 and the same problem with 2.4.20
The -ac1 patch helped because it booted just fine and I had dma on my
harddisk. But then I had problems mounting my dvd drive ... I'll try
the new -ac2 patch today, let's see if it makes any difference.
Btw: I think it depends what cd/dvd drive you have. I've heard from
other people with MSI KT3 Ultra2 who have no problem with 2.4.20
(without ac1 patch) and dma on disks plus dvd/cd/cdrw.
Patrick
^ permalink raw reply
* Re: playback in multiple period_size?
From: Jaroslav Kysela @ 2002-12-12 21:55 UTC (permalink / raw)
To: Guilhem Tardy; +Cc: alsa-devel@lists.sourceforge.net
In-Reply-To: <20021212205053.3929.qmail@web11507.mail.yahoo.com>
On Thu, 12 Dec 2002, Guilhem Tardy wrote:
> Hi all,
>
> I have come to realize that, whenever I drain() on a playback_handle to which a
> number of sample non-multiple of the period_size has been written, my
> application waits for several seconds to finally recover with an error EIO.
>
> Is the driver supposed to play audio if less than period_size is present in the
> buffer?
Yes.
> Is the application supposed to always add silence at the end to ensure that a
> multiple of period_size has been written?
It looks like a bug. Could you send me a little C code which triggers this
problem?
Jaroslav
-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
-------------------------------------------------------
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: NVRAM/RTC
From: Matt Porter @ 2002-12-12 21:52 UTC (permalink / raw)
To: Aman; +Cc: linuxppc embedded
In-Reply-To: <000901c2a20b$23472400$370da8c0@aman>
On Thu, Dec 12, 2002 at 11:50:23PM +0530, Aman wrote:
>
> Hi All
>
> I have customized board , which has PPC 440GP as its processor. In this
> board there is no NVRAM/RTC as in the 440GP evalkit. In the Rom monitor,
> configuration related to it NVRAM/RTC has been removed. Because of this
> changes in the rom monitor code, the linux image is hanging after " Now
> Booting the Kernel". If NVRAM/RTC EBC bank1 is enabled in rom monitor, the
> linux image is executing without any problem. Can anyone say , how to
> disable the NVRAM/RTC option in the linux kernel.
Are you trying to run an ebony image on this board? Sounds like it,
and that would be the wrong thing to do. Make a new port, and
in your <board>.c file, don't ioremap the RTC area (since you don't
have one) and delete (or set NULL) all the time/nvram machdeps.
Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply
* Re: Fwd: Re: sound card problem
From: - Luis - @ 2002-12-12 21:48 UTC (permalink / raw)
To: andrew.cramer; +Cc: linux admin
In-Reply-To: <3DE91E46.8112.D12B543@localhost>
On Saturday 30 November 2002 20:23, Andrew B. Cramer wrote:
hi, sorry i didnt answer before but i was out the city and i arrive just
today.
i cant resolve this yet, i try to get a new driver on www.linux.org but i
didnt know how to get it there.
give me a hand please
> Hi Luis,
> Did you get that resolved?
>
> Best - Andy
--
Luis Valencia
------------------------
With a PC, I always felt limited
by the software available.
On Unix, I am limited only by my knowledge.
--Peter J. Schoenster
^ permalink raw reply
* Re: Success! TWO questions remain
From: Hamish Moffatt @ 2002-12-12 21:45 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <200212120934.49608.n7ipb@koster.seatcp.net>
On Thu, Dec 12, 2002 at 09:34:49AM -0800, Ken Koster wrote:
> 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.
OK, my mistake. However I was under the impression that the original
poster was actually looking for a way to obscure his communications,
which the regulations don't allow.
> packet sites. While the fact that SSH also encrypts the rest of your
> communication besides the password might be considered by some to be
That can be disabled.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
^ permalink raw reply
* More progress on loading 2.5.50
From: Matt Young @ 2002-12-12 21:51 UTC (permalink / raw)
To: Linux Kernel Mailing List
PSAUX is not some fantastic French technology, it must be enabled.
My 3COM/USB adapter seems to be enabled correctly but the LCD lights do not
blink. Still testing.
95% there, although I did hack into do_mounts and force fed the proper root
device.
The patch for make that fixes make modules works fine, thank you.
Question: Can I turn REISERFS on and off for testing (does in nun on top of
EXT2)
Yast is a dog.
^ permalink raw reply
* Re: Success! TWO questions remain
From: Hamish Moffatt @ 2002-12-12 21:44 UTC (permalink / raw)
To: linux-hams
In-Reply-To: <Pine.LNX.4.33.0212120924130.1291-100000@wapiti.tc.fluke.com>
On Thu, Dec 12, 2002 at 09:27:40AM -0800, Curt Mills, WE7U wrote:
> On Thu, 12 Dec 2002, Margaret Leber wrote:
> > Hamish Moffatt wrote:
> > > 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.
With SSH set up for a private and public key pair, you aren't even
exchanging encrypted passwords.
The remote machine has your public key, and you have your private key.
The remote machine gives you something to encrypt using the private key
and send back to it (a challenge). If you don't have the private key it
is impossible to meet its challenge. If somebody else had the private
key they could provide the proper response too.
Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>
^ permalink raw reply
* Re: Status new-modules + 802.11b/IrDA
From: Benjamin Reed @ 2002-12-12 21:51 UTC (permalink / raw)
To: Rusty Russell, jt
Cc: Linux kernel mailing list, Benjamin Reed, Jeff Garzik, dahinds
In-Reply-To: <20021212003733.2AF922C0E0@lists.samba.org>
Sorry, I missed the original message.
As far as the timer message from airo_cs when you try
to remove the card: This executes some code that is
pretty much common to all PCMCIA drivers that sets a
timer to do the actual driver removal asynchronous to
the REMOVAL event. You can find it in airo_cs.c.
I'll update the driver.
I haven't tried the recent 2.5 kernels, so I check if
I see anything.
ben
In relation to:
--- Rusty Russell <rusty@rustcorp.com.au> wrote:
> In message
> <20021211174305.GB11264@bougret.hpl.hp.com> you
> write:
> > On Wed, Dec 11, 2002 at 07:34:53PM +1100, Rusty
> Russell wrote:
> > > > o removal of airo_cs : "Uninitialised
> timer!/nThis is a
> > > > warning. Your computer is OK". Call trace on
> demand. Also, the module
> > > > airo not removed (probably due to problem with
> airo_cs).
> > >
> > > That, in itself, should be harmless.
> >
> > Yes, but this is new and I don't really like it.
> I suspect
> > something is wrong in the Pcmcia code itself. Last
> I tried was 2.5.46
> > and I see some suspicious init_timer() added where
> I would not expect,
> > and some missing where they would be needed.
> > Hum... Who is in charge ?
>
> Well, Andrew Morton made the change that required
> timers to be
> initialized, and the check which locates ones which
> are not. As to
> who is responsible for airo_cs, I'm guessing Ben
> Reed, as author.
>
^ permalink raw reply
* Re: NFS mounted rootfs possible via PCMCIA NIC ?
From: H. Peter Anvin @ 2002-12-12 21:49 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <200212121829.46465.andreas.schaufler@gmx.de>
Followup to: <200212121829.46465.andreas.schaufler@gmx.de>
By author: Andreas Schaufler <andreas.schaufler@gmx.de>
In newsgroup: linux.dev.kernel
>
> ...
> > 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 ?!?
>
pivot_root() is a system call which flips the root directory around.
See Documentation/initrd.txt.
-hpa
--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com>
^ permalink raw reply
* Re: how to swap ctrl/caps lock keys for joe?
From: Ray Olszewski @ 2002-12-12 21:39 UTC (permalink / raw)
To: linux-newbie
In-Reply-To: <200212122108.OAA03810@cu.imt.net>
I don't do this myself, but there is a standard set of tools for remapping
the keyboard with Linux consoles. For the details (I can't say it any
better than they do), check the Keyboard and Console HowTo, available at
(for example):
http://www.tldp.org/HOWTO/Keyboard-and-Console-HOWTO.html
At , Jerry James Haumberger wrote:
>Under BasicLinux I've recently installed the joe editor for its
>jstar capabilities (which mimic WordStar). The actual DOS WordStar
>editor added a small binary to switch your Caps Lock and left
>Ctrl keys to make it easier to manipulate the WordStar navigation
>and command key combinations with the left small finger. (The
>older computer keyboards didn't have two Ctrl keys -- there was
>a Ctrl key just to the left of the "a" key that made Ctrl key
>combinations easy.) Under Linux, however, one must deal with
>key assignments under various shells and other programs that often
>change for each of these applications. I have not found in the
>joerc configuration file (or anywhere else, yet) where you can
>alter the Caps Lock/left Ctrl key assignments to accommodate an
>easier usage of joe/jstar.
>
>Has anyone else on the list encountered this need and found a
>working solution for the Linux console? I found a solution through
>a Google search for joe that works under X, but I'm not using X
>on this machine.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA ray@comarre.com
-------------------------------------------------------------------------------
-
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: pci-skeleton duplex check
From: Jeff Garzik @ 2002-12-12 21:39 UTC (permalink / raw)
To: Donald Becker; +Cc: Roger Luethi, netdev, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.44.0212121539110.10674-100000@beohost.scyld.com>
Donald Becker wrote:
> On Thu, 12 Dec 2002, Jeff Garzik wrote:
>
>>Donald Becker wrote:
>>
>>>[[ I don't know why I bother. The people that now control what goes into
>>>the kernel would rather put in random patches from other people than
>>>accept a correct fix from me. ]]
>>
>>I'm very interested in applying fixes from you! I am publicly begging
>>you to do so, and even CC'ing lkml on my request.
>
>
> This is very disingenuous statement.
Oh come on, it's far less disingenuous than what you said:
[[ I don't know why I bother. The people that now control what
goes into the kernel would rather put in random patches from
other people than accept a correct fix from me. ]]
I'm sure you'll continue making snide comments on every mailing list you
maintain, but the fact remains:
I would much rather accept a fix from you.
That hasn't changed in the past year. or two. or any amount of time.
Your input is very valuable, and I typically save quite a few of your
emails.
> The drivers in the kernel are now heavily modified and have significantly
> diverged from my version. Sure, you are fine with having someone else
> do the difficult and unrewarding debugging and maintainence work, while
> you work on just the latest cool hardware, change the interfaces and are
> concerned only with the current kernel version.
While I disagree with this assessment, I think we can safely draw the
conclusion that the problem is _not_ people ignoring your patches, or
preferring other patches over yours.
> I've been actively developing Linux drivers for over a decade, and run
> about two dozen mailing lists for specific drivers. I write diagnostic
> routines for every released driver. I thoroughly test and frequently
> update the driver set I maintain. And since about 2000, my patches were
> ignored while the first notice I've have gotten to changes in my drivers
> is the bug reports. And the response: "submit a patch to fix those
> newly introduced bugs". I've even had patches ignore in favor of people
> that wrote "I don't have the NIC, but here is a change".
I don't recall _ever_ getting a patch from you or seeing one posted on
lkml or netdev. How can you be ignored if you're not sending patches?
> A good example is the tulip driver. You repeatedly restructured my
> driver in the kernel, splitting into different files. It was still 90+%
> my code, but the changes made it impossible to track the modification
> history. The kernel driver was long-broken with 21143-SYM cards, but no
> one took the responsibility for fixing it.
s/was/is/
I take responsibility for fixing it, I just haven't fixed it yet :)
> It's easy to make the first few patches, when you don't have to deal
> with reversion testing, many different models, and have an unlimited
> sandbox where it doesn't matter if a specific release works or not. But
> it takes a huge of work to keep a stable, tracable driver development
> process that works with many different kernel versions and hardware
> environments.
We're slowly getting there, in terms of regression and stress testing.
Since you don't send patches anymore for a long time, I was really the
only one [stupid enough?] to stand up and even bother to help collecting
and reviewing net driver changes.
I would love to integrate your drivers directly, but they don't come
anywhere close to using current kernel APIs. The biggie of biggies is
not using the pci_driver API. So, given that we cannot directly merge
your drivers, and you don't send patches to kernel developers, what is
the next best alternative? (a) let kernel net drivers bitrot, or (b)
maintain them as best we can without Don Becker patches? I say that "b"
is far better than "a" for Linux users.
Jeff
^ permalink raw reply
* VT8235 and IDE problems
From: Marci @ 2002-12-12 21:31 UTC (permalink / raw)
To: linux-ide
Hi, I have a MSI KT4 Ultra MoBo with KT400 and VT8235 , before of this I
had an Apollo PRO 133 and all worked fine, with this mobo there isn't
DMA support for my southbridge in kernel 2.4.19 , so I've upgraded it to
2.4.20 , but I have a problem.
In the boot I see that he recognize my chip and turn on DMA on hda and
hdb (My HD) , but when it try to start DMA on my hdc (first DVD Reader)
It locks up with "hdc: DMA disabled" message, then it said about the
device that is BUSY , then it said "ide1: resetting!" and return to the
message above ("hdc:DMA...:") in an infinite loop.I don't know what to
do.I've tried to install ac2 patch for linux-2.4.20 tree, and it don't
lock up to hdc: DMA disabled (this appears again , but don't freeze
here) but when I try to enable ide-scsi module it freeze with messages
about SCSI problems, then it tries to resetting all the SCSI emulated
devices and this create an infinite loop of these messages!
What is the problem?
Thanks a lot
Bye
Marcello
^ permalink raw reply
* Re: 2.5.51 breaks ALSA AWE32
From: Sam Ravnborg @ 2002-12-12 21:32 UTC (permalink / raw)
To: Kai Germaschewski; +Cc: Sam Ravnborg, John Bradford, perex, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0212121454290.17517-100000@chaos.physics.uiowa.edu>
On tor, dec 12, 2002 at 02:55:28 -0600, Kai Germaschewski wrote:
> Nope, kbuild does that for you ;)
I recall this - now. Anyway the following fragment teels the full story :-)
cmd_link_multi-y = $(LD) $(LDFLAGS) $(EXTRA_LDFLAGS) -r -o $@ $(filter $(addprefix $(obj)/,$($(subst $(obj)/,,$(@:.o=-objs))) $($(subst $(obj)/,,$(@:.o=-y)))),$^)
In clear text:
For all prerequisite .o files (file.o) where there exist a -objs (file-objs)
or a -y (file-y) variable use the value of that variable instead.
> (And yes, lots of places still do it manually, but it's not necessary
> anymore).
I will take a look some day.
Sam
^ permalink raw reply
* libiptc and setsockopt
From: Aaron Eppert @ 2002-12-12 21:23 UTC (permalink / raw)
To: netfilter-devel
libiptc's iptc_commit(...) commit function appears to be
erroring out on rather valid data in the portion that
does a setsockopt() on SO_SET_REPLACE. The errno that is
set appears to be EAGAIN. Can anyone shed a bit of light
on the situation as to why this may happen. My application
is (unfortunately) using pthreads and all calls to libiptc
functions are wrapped with a mutex to prevent anyone from
calling into the library twice as I noticed it is hardly
thread safe.
Thank you for your time,
Aaron Eppert
^ permalink raw reply
* Re: kconfig (gkc) [PATCH]
From: Romain Lievin @ 2002-12-12 21:29 UTC (permalink / raw)
To: Roman Zippel; +Cc: Linux Kernel
In-Reply-To: <Pine.LNX.4.44.0211282111110.2113-100000@serv>
Hi,
Sorry, for the long time, I was waiting for GTK+ team to fix a bug...
> > BTW, I have fixed the problems you reported to me in gkc (gconf). gkc is now
> > working fine.
>
> I still saw some problems, e.g. try to play with SCSI_AIC7XXX.
Well, fixed... All stuffs seem to work fine now !
> A seperate target should do for now. I'm a bit concerned about the size. I
> tried to keep qconf small, so e.g. I didn't use the qt designer. gconf is
> now already larger than qconf. It might help to see it as complete patch
> and if not too many people complain, it would be far easier for me to send
> it on to Linus. :)
You will find a patch against 2.5.51 on http://tilp.info/perso/gkc.html.
>
> bye, Roman
>
>
Next step: add the 2 other views and use icons (by sharing yours).
Thanks, Romain.
--
Romain Lievin, aka 'roms' <roms@tilp.info>
The TiLP project is on <http://www.ti-lpg.org>
"Linux, y'a moins bien mais c'est plus cher !"
^ permalink raw reply
* Re: rmap15a swappy?
From: Sean Neakums @ 2002-12-12 21:21 UTC (permalink / raw)
To: linux-mm
In-Reply-To: <Pine.LNX.4.50L.0212121913030.17748-100000@imladris.surriel.com>
commence Rik van Riel quotation:
> On Thu, 12 Dec 2002, Sean Neakums wrote:
>
> Indeed, the older rmaps swapped later. However, swapping
> a little bit earlier turns out to be faster for almost all
> workloads.
Oh right, because if you get sudden memory pressure you have a bunch
of pages that you can just throw away without writeout?
Anyway, that's nifty. I just wanted to make sure it wasn't a
regression.
--
/ |
[|] 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
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.