Re: pkgupgrade
On Sat, Feb 10, 2007 at 04:40:28PM +0100, Michel Talon wrote: Hello, this is to report a revised version of my program, intended to upgrade a machine using mainly precompiled packages. All problems that i have seen or have been reported to me have been fixed. So i think it is reasonably suitable for use, and i have sticked a 1.0 label. I have also fixed all problems i have encountered with save_pkg.py, but Cyrille Szymanski will perform a better cleanup, so i have appended a 0.5 tag. So fresh copies can be downloaded from: http://www.lpthe.jussieu.fr/~talon/pkgupgrade-1.0 http://www.lpthe.jussieu.fr/~talon/save_pkg.py-0.5 Hi Michel. Good work, this script is pretty cool! One thing that might be nice to add is an option to download new packages from the packages-X-stable directory, if a newer version is found there. I think you only ever look in packages-X.Y-release at the moment, and those never change after the release as far as I know. Best regards, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pkgupgrade
On Sun, Feb 11, 2007 at 01:31:59PM -0500, Mike Meyer wrote: In [EMAIL PROTECTED], Scott Mitchell [EMAIL PROTECTED] typed: Good work, this script is pretty cool! One thing that might be nice to add is an option to download new packages from the packages-X-stable directory, if a newer version is found there. I think you only ever look in packages-X.Y-release at the moment, and those never change after the release as far as I know. While the option might be useful, you may want to build from source in that case. While ports that postdate X.Y are supposed to build and run correctly on X.Y (for supported values of X Y), and packages built on systems that predate X.Y are supposed to run correctly on X.Y, packages built on systems that postdate X.Y may not run correctly on X.Y. If you're already doing thorough testing of the system after you upgrade the packages, this doesn't really make much difference. But if you're expecting that the testing was done by someone else, your expectations don't match reality. Yup, I know all that. I wouldn't do that kind of upgrade on a server, but on my workstation, with copies of the old packages around just in case, I'm willing to take that (in practice very small) risk, if only to avoid spending the half a day it takes to rebuild KDE from source :( Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: region code in cdrecord
On Sun, Apr 24, 2005 at 11:48:42AM +0930, Daniel O'Connor wrote: On Sun, 24 Apr 2005 09:59, Chuck Robey wrote: Now, I want to go for broke, and try for the one I've been after for years, which is converting a region==2 dvd to a region==1 dvd (Britain to US). I have a dvd taht you can't buy in the US, I've tried, and the British won't sell it in region code 1, so I want to convert the one I went ahead and purchased anyhow. Once I get it converted, I figure I can toss out the old region==2 version and remain lily-white and pure as far as honesty goes. The region code is part of the VOB/IFO files that contain the DVD, not as a part of the ISO metadata. You will need another tool to change region, I know DVD Decrypter [http://www.dvddecrypter.com/] does it for Win32. Maybe transcode? I may be completely off base here (no experience with making DVDs other than as enormous CDR's for backup), but does it need to be region coded at all? Even region-locked players should be able to play a dvd with no region code. I think 'no region code' might actually be region 0, but it amounts to the same thing. IMHO there's nothing dishonest in taking whatever steps you need to play a piece of legitimately purchased media. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: region code in cdrecord
On Sun, Apr 24, 2005 at 11:48:42AM +0930, Daniel O'Connor wrote: On Sun, 24 Apr 2005 09:59, Chuck Robey wrote: Now, I want to go for broke, and try for the one I've been after for years, which is converting a region==2 dvd to a region==1 dvd (Britain to US). I have a dvd taht you can't buy in the US, I've tried, and the British won't sell it in region code 1, so I want to convert the one I went ahead and purchased anyhow. Once I get it converted, I figure I can toss out the old region==2 version and remain lily-white and pure as far as honesty goes. The region code is part of the VOB/IFO files that contain the DVD, not as a part of the ISO metadata. You will need another tool to change region, I know DVD Decrypter [http://www.dvddecrypter.com/] does it for Win32. Maybe transcode? I may be completely off base here (no experience with making DVDs other than as enormous CDR's for backup), but does it need to be region coded at all? Even region-locked players should be able to play a dvd with no region code. I think 'no region code' might actually be region 0, but it amounts to the same thing. IMHO there's nothing dishonest in taking whatever steps you need to play a piece of legitimately purchased media. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
Well, -standards says that POSIX is silent on the subject of ls and nanoseconds, so I guess we can do whatever we like... I was going to just commit my original patch and be done with it, but David appears to have beaten me to it: http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ls/cmp.c Anyway, bikeshed over :-) Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Mon, Jun 21, 2004 at 09:10:47AM +0100, David Malone wrote: Sorting on nanoseconds too is likely to be more confusing than useful. Even if we use one of the precious few option letters ls doesn't use already to add a nanosecond display, most people won't know about it because they don't care about nanoseconds. They might care when they notice---as you did---that the sort order isn't what they expected. At the moment in FreeBSD the nanoseconds field is always zero, unless you twiddle vfs.timestamp_precision, so it would make no difference to joe user. For people that do set vfs.timestamp_precision, it would be nice if ls did the right thing (for example, test already compares the nanoseconds field, after someone submitted a PR because it didn't). I've asked the -standards people whether POSIX says anything about ls and nanoseconds. My research didn't turn up anything, but I'll let them have the final word. Given that our ls has ignored nanos for at least the last 10 years, and that it would make difference to 99% of users if it did, I don't think this is a major issue. I'm tempted to just commit the existing patch as it is, to fix the original bug, then talk about sorting on nanos, and maybe adding a new option to display them. Is the point of sorting on nanoseconds to totally order the files based on modification time? Depending on the clock resolution (which is partially determined by vfs.timestamp_precision and partially determined by the actual clock resolution), it may not be enough to totally order the files. But it (ls) would use the full resolution of the recorded timestamps to produce the displayed ordering, which is probably all you can reasonably ask of it... Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Sun, Jun 20, 2004 at 09:59:12AM +0100, David Malone wrote:
On Sat, Jun 19, 2004 at 11:52:29PM +0100, Scott Mitchell wrote:
On Sat, Jun 19, 2004 at 10:06:01PM +0200, Dimitry Andric wrote:
Looking through ls source shows that the sorting is done by passing a
comparison function to fts_open(3). In the case of sorting by
modification time, the *only* comparison made is of the mtime fields:
You did see the patch attached to my original post, right? It modifies all
of these comparison functions to sort the two items by name (or reverse
name) in the case that their timestamps are equal.
Hi Scott,
Could you produce a version of your patch that uses the nanoseconds
field too? I produced the one below, but I think the style in your
patch was nicer. Also, I wonder if the revblahcmp functions should
just call blahcmp with their arguments reversed?
David.
David,
New patch attached that compares against the nanos field as well. It could
stand a bit of cleaning up to remove the overly long lines.
I'm not sure I'd want this in the tree unless we also had an option to
display the nanoseconds - as it stands you could get items apparently
ordered wrongly, unless you knew the value of their nanos fields. I could
do that if people thought it would be useful.
Scott
--
===
Scott Mitchell | PGP Key ID | Eagles may soar, but weasels
Cambridge, England | 0x54B171B9 | don't get sucked into jet engines
scott at fishballoon.org | 0xAA775B8B | -- Anon
Index: cmp.c
===
RCS file: /home/ncvs/src/bin/ls/cmp.c,v
retrieving revision 1.13
diff -u -r1.13 cmp.c
--- cmp.c 6 Apr 2004 20:06:47 - 1.13
+++ cmp.c 20 Jun 2004 14:33:14 -
@@ -63,35 +63,47 @@
int
modcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_mtime - a-fts_statp-st_mtime);
+ return (a-fts_statp-st_mtimespec.tv_sec == b-fts_statp-st_mtimespec.tv_sec
?
+ (a-fts_statp-st_mtimespec.tv_nsec ==
b-fts_statp-st_mtimespec.tv_nsec ?
+ namecmp(a, b) :
+ b-fts_statp-st_mtimespec.tv_nsec -
a-fts_statp-st_mtimespec.tv_nsec) :
+ b-fts_statp-st_mtimespec.tv_sec -
a-fts_statp-st_mtimespec.tv_sec);
}
int
revmodcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_mtime - b-fts_statp-st_mtime);
+ return modcmp(b, a);
}
int
acccmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_atime - a-fts_statp-st_atime);
+ return (a-fts_statp-st_atimespec.tv_sec == b-fts_statp-st_atimespec.tv_sec
?
+ (a-fts_statp-st_atimespec.tv_nsec ==
b-fts_statp-st_atimespec.tv_nsec ?
+ namecmp(a, b) :
+ b-fts_statp-st_atimespec.tv_nsec -
a-fts_statp-st_atimespec.tv_nsec) :
+ b-fts_statp-st_atimespec.tv_sec -
a-fts_statp-st_atimespec.tv_sec);
}
int
revacccmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_atime - b-fts_statp-st_atime);
+ return acccmp(b, a);
}
int
statcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_ctime - a-fts_statp-st_ctime);
+ return (a-fts_statp-st_ctimespec.tv_sec == b-fts_statp-st_ctimespec.tv_sec
?
+ (a-fts_statp-st_ctimespec.tv_nsec ==
b-fts_statp-st_ctimespec.tv_nsec ?
+ namecmp(a, b) :
+ b-fts_statp-st_ctimespec.tv_nsec -
a-fts_statp-st_ctimespec.tv_nsec) :
+ b-fts_statp-st_ctimespec.tv_sec -
a-fts_statp-st_ctimespec.tv_sec);
}
int
revstatcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_ctime - b-fts_statp-st_ctime);
+ return statcmp(b, a);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
/bin/ls sorting bug?
Hi all,
ls(1) says that the -t option will:
Sort by time modified (most recently modified first) before sort-
ing the operands by lexicographical order.
which I take to mean that items (in the same directory) with the same
timestamp should be further sorted according to their names. Unfortunately
it doesn't really work that way:
(562) tuatara:/tmp/foo $ ls -lt
total 0
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:48 c
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 b
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 d
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 e
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 f
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 g
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 h
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 i
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 j
-rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 a
-rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 k
This is on a 4.10-PRERELEASE machine, but the -CURRENT code seems to be
identical as far as sorting goes.
Is this intended behaviour? If so, the documentation is wrong. Otherwise,
the attached patch produces the expected output. I can commit it if there
are no objections.
Scott
--
===
Scott Mitchell | PGP Key ID | Eagles may soar, but weasels
Cambridge, England | 0x54B171B9 | don't get sucked into jet engines
scott at fishballoon.org | 0xAA775B8B | -- Anon
Index: cmp.c
===
RCS file: /home/ncvs/src/bin/ls/cmp.c,v
retrieving revision 1.9.2.2
diff -u -r1.9.2.2 cmp.c
--- cmp.c 8 Jul 2002 06:59:27 - 1.9.2.2
+++ cmp.c 19 Jun 2004 16:54:55 -
@@ -67,35 +67,47 @@
int
modcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_mtime - a-fts_statp-st_mtime);
+ return (a-fts_statp-st_mtime == b-fts_statp-st_mtime ?
+ namecmp(a, b) :
+ b-fts_statp-st_mtime - a-fts_statp-st_mtime);
}
int
revmodcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_mtime - b-fts_statp-st_mtime);
+ return (a-fts_statp-st_mtime == b-fts_statp-st_mtime ?
+ revnamecmp(a, b) :
+ a-fts_statp-st_mtime - b-fts_statp-st_mtime);
}
int
acccmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_atime - a-fts_statp-st_atime);
+ return (a-fts_statp-st_atime == b-fts_statp-st_atime ?
+ namecmp(a, b) :
+ b-fts_statp-st_atime - a-fts_statp-st_atime);
}
int
revacccmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_atime - b-fts_statp-st_atime);
+ return (a-fts_statp-st_atime == b-fts_statp-st_atime ?
+ revnamecmp(a, b) :
+ a-fts_statp-st_atime - b-fts_statp-st_atime);
}
int
statcmp(const FTSENT *a, const FTSENT *b)
{
- return (b-fts_statp-st_ctime - a-fts_statp-st_ctime);
+ return (a-fts_statp-st_ctime == b-fts_statp-st_ctime ?
+ namecmp(a, b) :
+ b-fts_statp-st_ctime - a-fts_statp-st_ctime);
}
int
revstatcmp(const FTSENT *a, const FTSENT *b)
{
- return (a-fts_statp-st_ctime - b-fts_statp-st_ctime);
+ return (a-fts_statp-st_ctime == b-fts_statp-st_ctime ?
+ revnamecmp(a, b) :
+ a-fts_statp-st_ctime - b-fts_statp-st_ctime);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Sat, Jun 19, 2004 at 09:01:37PM +0200, Dimitry Andric wrote: On 2004-06-19 at 19:50:07 Scott Mitchell wrote: (562) tuatara:/tmp/foo $ ls -lt total 0 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48 c -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 b -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 d -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 e -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 f -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 g -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 h -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 i -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 j -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13 a -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13 k Can you please show the output of ls -ltT ? Sure (added -i to make it easier to see what's going on here): (505) tuatara:/tmp/foo $ ls -iltT total 0 35 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:48:40 2004 c 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 b 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 d 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 e 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 f 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 g 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 h 41 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 i 51 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 j 11 -rw-rw-r-- 7 scott wheel 0 19 Jun 17:13:36 2004 a 52 -rw-rw-r-- 1 scott wheel 0 19 Jun 17:13:36 2004 k Most of those files (a,b,d,e,f,g,h) are hard-linked to each other - so they definitely share the same timestamp. i,j,k were created with 'touch -r a i j k', so they should also have the same time. c is different to make sure I didn't break the sort order when files *did* have different times. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /bin/ls sorting bug?
On Sat, Jun 19, 2004 at 11:47:21AM -0700, Tim Kientzle wrote: Scott Mitchell wrote: ls(1) says that the -t option will: Sort by time modified (most recently modified first) before sort- ing the operands by lexicographical order. ... the attached patch produces the expected output. I can commit it if there are no objections. Looks good to me. I wonder if the time sorting should include the nanos field as well. (Mostly on FreeBSD, the nanos field is zero, but not always.) I don't see why not, unless some standard requires the nanos to be ignored. That would be pretty strange though... Of course, sorting on the (non-displayed) nanos field could also produce such unexpected output as you describe. I guess you'd want yet another option to display the full-resolution timestamp, if you were going to sort on the whole thing. And you'd still want to use the name to break ties. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP.. USB MFC coming..
On Fri, Feb 27, 2004 at 05:54:18PM -0800, Julian Elischer wrote: I plan to commit the MFC at http://www.josef-k.net/freebsd/ (the latest one) in the next couple of days. If you really care about USB in 4.10 you might do well to test this on your equipment, ESPECIALLY if you have unusual devices. Let me know of both successes and failures please.. If I hear nothing I won't know if it's because no-one tested it or it was just without problems.. Hi Julian, The usb.ko module failed to load with these patches (usb_allocmem undefined). Adding usb_mem.c to SRCS in /sys/modules/usb/Makefile seems to fix this - my USB mouse, flash reader and cheap-ass 'pen drive' all appear to be working as before. One strange thing though - booting from my usual kernel (which loads most things from modules) I get some extra whining when the USB ports are being probed: uhci0: VIA 83C572 USB controller port 0xd800-0xd81f irq 10 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhub0: port error, restarting port 1 uhub0: port error, giving up port 1 umass0: Generic Mass Storage Device, rev 1.10/1.00, addr 2 umass0: Get Max Lun not supported (STALLED) uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 umass1: DMI MultiFlash, rev 1.10/1.00, addr 3 uhci1: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 10 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub1: port error, restarting port 1 uhub1: port error, giving up port 1 ugen0: LEGO Group LEGO USB Tower, rev 1.10/1.00, addr 2 uhub1: port error, restarting port 2 uhub1: port error, giving up port 2 ums0: Logitech USB Receiver, rev 1.10/9.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. Booting from a GENERIC built from the same sources, I don't get any of the 'port error' messages: uhci0: VIA 83C572 USB controller port 0xd800-0xd81f irq 10 at device 7.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: Generic Mass Storage Device, rev 1.10/1.00, addr 2 umass0: Get Max Lun not supported (STALLED) umass1: DMI MultiFlash, rev 1.10/1.00, addr 3 uhci1: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 10 at device 7.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ugen0: LEGO Group LEGO USB Tower, rev 1.10/1.00, addr 2 ums0: Logitech USB Receiver, rev 1.10/9.10, addr 3, iclass 3/1 ums0: 5 buttons and Z dir. This doesn't seems to have any effect on whether things work or not though, other than the umass devices coming up on different SCSI busses if I don't load USB from the module, but I think that has always been the case. Otherwise it looks good. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xircom CEM56 problem
On Sat, Feb 21, 2004 at 05:58:30AM +, RMH wrote: Hello hackers, I have a problem with Xircom CEM56 (Ethernet + Modem) PC Card. I know it isn't really possible on 4.x to use both network modem parts at the same time, but how to switch between them without rebooting? For example, if I've booted with pccardd configured for either, then I edit pccard.conf (a symlink to a real network or modem .conf file), and what next? kldunload if_xe.ko if loaded already, kill -s HUP [pccardd_pid] or just kill -9 [pccardd_pid] and restart don't seem to have a desired effect because kernel (pccard) complaints that it cannot attach more than one child. But upon rebooting it probes the hardware just fine. How may I reset pccard on the fly? A working solution is to pull the card and install it into a second slot, but I guess it's not the best idea, because after several such swaps I've got a page fault an a kernel panic... Hi Rhett, I have a couple of scripts that I use when I need to swaps cards and/or drivers, when I'm working on the xe driver. This is on -CURRENT, but using the OLDCARD driver framework, so it will hopefully work on 4.x as well: To shutdown the card: ifconfig xe0 down kill `cat /var/run/dhclient.pid` pccardc power 0 0 sleep 2 kldunload if_xe To bring it back up again after recompiling the driver or swapping cards: kldload if_xe pccardc power 0 1 The 'pccardc power' commands simulate removing and re-inserting the card. In your case you'll obviously need to switch pccard.conf and bounce pccardd while the card is powered down. If this still triggers a panic, could you file a PR on it? If it's something in the xe driver I'll take a look at it. Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SimpleTech USB HDD driver
On Tue, Sep 23, 2003 at 08:33:15AM +0200, Devon H. O'Dell wrote: Scott Mitchell wrote: This is fine - just an informational message rather than anything actually wrong. Out of curiosity, what does that indicate (or where can I find comments in the source)? As I understand it, the USB mass storage protocol uses SCSI commands, which is why you end up mounting /dev/da0 to see your drive. For reasons I'm not familiar with, there are two flavours of these SCSI commands around - 6 byte and 10 byte. I believe the driver always tries to use 6 byte commands first and falls back to 10 byte if the shorter commands are not supported. You used to need a quirk entry for such devices (to force the driver to only use 10 byte commands) but things have improved to the point that quirks are now only needed for really screwed up devices. No idea why both 6 byte and 10 byte commands exist. No doubt someone out there knows the historical background to it all. Yes, I also got an email from the product manager of the SimpleDrive asking me what sort of documentation I was looking for. This seems like an open-source friendly company; just so that we can keep this in mind in case there are portable storage device/hard drive issues in the future. It looks like Firewire is also taken care of, but you never know what else there might be in the future. That's good news. Cheers, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SimpleTech USB HDD driver
On Mon, Sep 22, 2003 at 08:24:06AM -0400, [EMAIL PROTECTED] wrote: I just bought a 120GB SimpleTech USB harddrive and I want to use it with FreeBSD 4.8 (the HDD is part number STI-U2F35/120). AFAIK, 4.8 doesn't support USB HDDs. Why is this? Did you try plugging it in? If it really is a USB mass storage device, it is supported and should just work. All the necessary drivers are already there in the GENERIC kernel. Some devices might require 'quirks' to be added to the kernel to get them to work with 4.8 or earlier, but I think even this requirement has mostly gone away in 4.9. You might want to take a look at Dan Pelleg's DaemonNews article: http://ezine.daemonnews.org/200305/cfmount.html. It talks about CF devices but the part dealing with USB should also apply to disks. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SimpleTech USB HDD driver
On Mon, Sep 22, 2003 at 09:12:50AM -0400, [EMAIL PROTECTED] wrote: Hey Scott, I just bought the thing and I'm at work, so I haven't had a chance to try it out yet. I've sent a message to the SimpleTech support people... hopefully they're OSS friendly. I'll give more information as I have it. I was under the impression though that USB HDDs were unsupported in RELENG_4; I may be totally off base, in which case I apologize for sending unnecessary emails to the list. Thanks for the link to the article; I'll let you know about my sucesses/failures. --Devon No worries - it's what the lists are for. AFAIK all USB mass storage devices should be supported by the umass driver, but some devices will have issues. I use various flash cards and 'pen drives' all the time - a real hard disk should look the same to the driver. Bear in mind that 4.x only supports USB 1.1, so even if you have USB 2.0 ports on your machine, and a USB 2.0 drive, the most you'll get out of it is somewhere in the region of 1 MB/s. Look forward to hearing of your success - good luck! Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SimpleTech USB HDD driver
On Mon, Sep 22, 2003 at 04:48:16PM +0200, Devon H. O'Dell wrote: Well, what do you know, a quick mount_msdos /dev/da0s1 worked just fine ;). Something to add to the hardware compatibility list I guess. Here's the dmesg entry: umass0: In-System Design USB Storage Adapter, rev 2.00/11.01, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: IC35L120 AVV207-0 V24O Fixed Direct Access SCSI-0 device da0: 650KB/s transfers da0: 117800MB (241254720 512 byte sectors: 64H 32S/T 52264C) I did get the below message, but it does not seem to goof up anything. (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. This is fine - just an informational message rather than anything actually wrong. Thanks for setting my head straight about this. I think this should be listed on the web page. The reason I asked in the first place is because there are no mailing list articles about this (that Google could find with about 31899821498 different queries, anyway ;) and the webpage gives me the idea that it doesn't support larger devices. Indeed... the docs should probably just list the classes of device that should work, rather than specific instances. I did once start updating the umass(4) manpage to say this, but got discouraged by a flurry of list messages complaining that XYZ device didn't work - didn't feel up to documenting the intricacies of the quirking mechanism. Now that this is less of a problem, I should probably pick that up again. Anyway, glad you got it working. Cheers, Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Out of Office AutoReply: LinkSys WPC54G PCCARD (fwd)
On Sat, Jun 21, 2003 at 05:12:20PM +0200, Soeren Straarup wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi how is it normal to treat auto email replies like this one? Best regards Søren Hi Søren, Best thing to do with these messages is ignore them :-) It's just MS Outlook being lame and sending autoreplies to messages that weren't even addressed to the person on vacation. Followups to -chat, please... Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RBEM10/100+56k at 32-bit cardBus
On Fri, May 30, 2003 at 11:38:21AM +0400, Victor Bratsev wrote: Greetings! Can anybody help me to solve this - I've got RBEM10/100+56k PCMCIA card and I can't get it work. Because my cardBus - it's 32-bit, and driver is 16-bit. I've got a message at startup pcmcia: 32-bit cardbus is unsupported and as result if_xe.ko is unloaded with strange fhdjklsah - if I try to kldload if_xe it says that it can't load module because it is already loaded, but kldstat says that there is NO if_xe loaded. FreeBSD is RELEASE-4.7 with custom kernel with device xe included. CardBus is not supported at all in 4.x. If you want to use this card you'll have to upgrade to 5.x (which should be less of a scary option now that 5.1-R is nearly here). I'm pretty sure that the RBEM cards do work with 5.x, although I can't remember which driver they use. The xe driver only supports 16-bit Xircom cards, though. Their CardBus stuff uses entirely different hardware. Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make world + kernel with gcc 3.2?
On Sat, Mar 15, 2003 at 07:08:40PM +0100, Thierry Herbelot wrote: Le Saturday 15 March 2003 18:14, Avleen Vig a écrit : I don't expect HUGE problems with making world, but am I asking for trouble if I make a new kernel with GCC3.2? good luck to you ! just have a look at the differences in the source code between current and stable to enable the compilation of current with gcc3 (FriBi -Stable will not compile with anything other than gcc 2.95) TfH I assume the OP installed gcc3 from ports...in this case the gcc2.95 system compiler will still be installed as well. I'm pretty sure that a kernel build will explicitly use the system compiler, and buildworld/buildkernel certainly do (I believe buildworld actually builds a fresh copy of gcc2.95 then uses that to build the rest of the system). As Thierry says, trying to build -stable with gcc3 is probably doomed to failure. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines scott at fishballoon.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 5400RPM|7200RPM Cable bottleneck?
On Fri, Jan 17, 2003 at 06:18:38PM -0600, Jay Sern Liew wrote: Greetings. Does anyone know if a NFS server with a 7200RPM IDE HD will perform significantly better than a 5400RPM IDE HD over a cable connection? I'm assuming that the performance will only be noticable iff the NFS client is close(geographically) to the NFS server, i.e. same LAN since the bottleneck would be at the network level. If by 'cable' you mean a cable modem providing at best a few Mb/s bandwidth, then I doubt the speed of your disk will have any impact whatsoever. Even the crappiest ATA disk will be able to deliver a few MB/s -- in the worst case that's still an order of magnitude more than you can stuff down your cable modem. On the other hand, on a 100Mb/s LAN you likely will notice the difference, especially if your server has multiple users. Also, if the 5400RPM IDE HD was RAIDed, would that match an unRAIDed 7200RPM IDE HD? Thanks in advance. Depends on what sort of RAID it is and what you're doing with it. HTH, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dhcp problems with my ISP
On Sat, Aug 03, 2002 at 05:39:19PM -0700, Julian Elischer wrote: sometimes it's the cable modem that is cachingthe MAC address. whenever you change machines you need to power down and power up the cable modem. It might also be worth trying this: - Note when your current DHCP lease is set to expire (ipconfig /all or winipcfg on various versions of Windows, grovel through /var/db/dhcient.leases on FreeBSD). - If possible, manually release the lease (ipconfig /release or the appropriate button on winipcfg will do this on Windows, killing dhclient may be as close as you can get on a FreeBSD box). - Power off the cable modem and gateway box. - Wait for the lease expiry time to pass. Use the downtime to set up your network the way you want it, with the FreeBSD machine connected to the CM. - Once the lease expiry time has come and gone, power up the CM and (new) gateway box. With a bit of luck dhclient will be able to get a lease. This definitely works with my cable provider (ntl) but will obviously fail if your provider caches MAC addresses more persistently. Probably still easier to just swap the NICs, or call them up and say My NIC broke. Here's the MAC address of the one I'll be using from now on. When they ask what OS you're using, say Windows. :-) Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD NIS serving linux clients.
)/$@ - $(TMP); \
+ $(RMV) $(TMP) $@
+ @$(DBLOAD) -c
+ @if [ ! $(NOPUSH) ]; then $(YPPUSH) -d $(DOMAIN) $@; fi
+ @if [ ! $(NOPUSH) ]; then echo Pushed $@ map. ; fi
+ .endif
+
+
+ shadow.byname: $(MASTER)
+ @echo Updating $@...
+ .if ${MASTER} == /dev/null
+ @echo Master.passwd source file not found -- skipping
+ .else
+ $(CAT) $(MASTER) | \
+ $(AWK) -F: '{ if ($$1 != $$1 !~ ^#.* $$1 != +) \
+ print $$1\t$$1:$$2:12345:0:9:7::: }' $^ \
| $(DBLOAD) ${S} -f -i $(MASTER) -o $(YPMAPDIR)/$@ - $(TMP); \
$(RMV) $(TMP) $@
@$(DBLOAD) -c
--
===
Scott Mitchell | PGP Key ID | Eagles may soar, but weasels
Cambridge, England | 0x54B171B9 | don't get sucked into jet engines
[EMAIL PROTECTED] | 0xAA775B8B | -- Anon
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 09:40:07PM -0500, Craig Rodrigues wrote: I am a contributor to ACE, a cross-platform C++ library for doing systems programming: http://www.cs.wustl.edu/~schmidt/ACE.html. My intent is to fix the macros in ACE which define the configuration on FreeBSD (all FreeBSD specific configuration data is in ACE's config-freebsd-pthread.h). Right now the ACE macros which detect AIO and RT signals are broken, so I am trying to fix these macros, hence my questions on this mailing list. I'm not looking to specifically use POSIX RT signals on FreeBSD, I just want to get ACE to cleanly compile on FreeBSD, so that FreeBSD users can use and enjoy ACE on their projects if they choose. Craig, does this mean there is likely to be a port of ACE (and TAO) anytime soon? My company is using TAO in one of our products and I had started looking into getting it to compile nicely on FreeBSD with a view to creating a port eventually. If you're already an ACE contributor you'll no doubt do a better job of that than me, but feel free to pick on me for beta-testing as necessary :-) Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: getting started with -CURRENT
On Thu, Feb 28, 2002 at 10:58:33AM +1000, Greg Black wrote: Michael Lucas wrote [top post put down where it belongs]: | On Wed, Feb 27, 2002 at 02:23:31PM -0500, Steve Tremblett wrote: | Thanks for the help - much appreciated. | | I guess I'm misunderstanding the primary disk partitions and their | types - I seem to recall PCs getting cranky when there are multiple | primary partitions of the same type? Or is it that WINDOWS gets cranky | when it sees that? | | That would probably be Windows. I'm doing exactly this, without | trouble. No, there's no problem doing this with Windows (at least with Windows-ME) -- I have Win-ME on my laptop (so I can say it works under Windows when something is broken) with two FreeBSD partitions: 4.3-R (which works) and -CURRENT (in which PCMCIA is completely broken). But booting any of the 3 OSes works fine. Greg Not quite the same thing, but IME Windows (at least up to Win2K), *really* likes to have the first partition table entry for itself, and to live at the start of the disk. I had a horrible time getting W2K to install at the slow end of the disk on this machine -- where it belongs, as I use it perhaps 5% of the time -- manual editing of the partition table was needed in the end :-( I've certainly had machines with multiple, primary Windows partitions before now, with no obvious problems. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PAM, setusercontext, kdm and ports/32273
On Sat, Jan 26, 2002 at 04:52:03PM -0800, Terry Lambert wrote: Scott Mitchell wrote: However, this got me thinking -- is the right solution here to have a PAM module that does the setusercontext(), so programs that already know about PAM will just work, without needing to know about setusercontext() as well? I can see that causing problems with programs (login, xdm, etc.) that already understand both mechanisms, but they could always not use this hypothetical pam_setusercontext module, right? So, is this a worthwhile thing to have? I'm happy to either write the PAM module or fix kdm, but I'd rather not waste my time learning about PAM internals if people think this would be a pointless exercise. No. THis is a bad idea. Fix KDM instead. OK, but could you explain *why* you think it's a bad idea? Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PAM, setusercontext, kdm and ports/32273
On Sun, Jan 27, 2002 at 04:20:30AM -0800, Terry Lambert wrote: Scott Mitchell wrote: OK, but could you explain *why* you think it's a bad idea? It adds a side effect that wasn't there before in order to work around an improper usage of an interface. It adds some additional, optional behaviour that you can choose to turn on for those cases that would benefit from it... I wasn't suggesting that it become any kind of default. It's very bad to add a side effect that changes the API behaviour into a platform dependent API behaviour. It's very bad to have side effects, even if they are documented (look at the effort that is currently going into wedging an error return value into the external global errno for strtod()'s 0.0 case, in another thread). It's very bad to add a complex behaviour that can be aggregated out of a set of simple behaviours, instead. It's bad to change an abstraction layer; it's possible for a program to want to avoid the side effect, and find itself unable to do so, as well, which would mean that the interface abstraction itself was damaged by the change. Fair enough -- I agree with all that in general. In this case, though, surely kdm is going to be exposed to unknown side effects from its use of PAM anyway... I'll accept that there might be bad interactions between PAM and setusercontext() that I haven't considered. I'm not familiar enough with PAM to know what those would be. Basically, xdm demonstrates that the problem is that kdm is using the interface wrong, and should be changed to do what xdm does. xdm demonstrates that it was easy to hack to exhibit the desired behaviour, not necessarily that it's the right way to do it. In any case, hacking kdm is considerably less work, so I might as well do that first. Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PAM, setusercontext, kdm and ports/32273
Hi all, I've been looking at PR ports/32273, after noticing that kdm wasn't picking up my lang and charset selections from ~/login_conf. The problem seems to be that kdm thinks PAM and setusercontext() are mutually exclusive, and it's built with PAM enabled by default. Fixing kdm to DTRT in this situation -- I'm defining the Right Thing as 'how xdm does it' -- looks to be pretty simple. However, this got me thinking -- is the right solution here to have a PAM module that does the setusercontext(), so programs that already know about PAM will just work, without needing to know about setusercontext() as well? I can see that causing problems with programs (login, xdm, etc.) that already understand both mechanisms, but they could always not use this hypothetical pam_setusercontext module, right? So, is this a worthwhile thing to have? I'm happy to either write the PAM module or fix kdm, but I'd rather not waste my time learning about PAM internals if people think this would be a pointless exercise. I await your pearls of wisdom... Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ANyone seen a touch screen on BSD?
On Tue, Jan 22, 2002 at 10:12:01AM -0800, Julian Elischer wrote: says it all. If you know of a touch screen that can be interfaced to FreeBSD let me know.. Depends what you mean by 'interfaced'... we had some touch screens attached to RedHat boxen at my previous job -- the touch screen bit just emulated a mouse (plugged into the serial port, IIRC). They supplied XFree86 drivers for it and a bit of software for calibrating the thing. I remember thinking at the time, there was no reason this wouldn't run on *BSD as well. If you're interested, I'll get someone there to dig out the details of where we got them from. The suppliers were pretty helpful (they built the screens as well as selling them), so all other things being equal I'd recommend them. HTH, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Xircom Card
Sorry if this appears multiple times; it didn't show up on -hackers after 24 hours, so I'm sending again... - Forwarded message from Scott Mitchell scott - On Sun, Apr 30, 2000 at 03:44:46AM -1000, FreeBSD MAIL wrote: I just cvsuped and built a kernel as of Sun Apr 30 03:20:08 HST 2000. Despite the probing which goes on when I insert the card and somtimes shortly after I ifconfig it, the Xircom 16bit card seems to work fine. Despite all those "couldn't allocate..." messages in your previous post? That's weird, but I'm glad to see it working. You'll probably get more feedback on this from -mobile or freebsd-xircom (http://www.lovett.com/lists/freebsd-xircom/ for details of that list). Myself and the rest of the Xircom developers definitely read those, I'm not sure that we're all on -hackers though. I also have a Card Buss Xircom card which I could also test with. Don't bother -- it's based on very different hardware to the 16-bit models, with no driver support as yet. Scott -- ======= Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting linux drivers to FreeBSD
On Tue, Mar 14, 2000 at 04:14:50PM -0800, Don Wallwork wrote: Hi- I found a linux driver for my Xircom PCMCIA ethernet card at: http://pcmcia.sourceforge.org/ Which card was that? All of the recent Xircom PCMCIA cards are supported by the xe driver in 3.x Are there any pointers available on porting linux drivers to FreeBSD? I'm not aware of any, but for network drivers at least it's pretty easy regardless. To a certain level, a driver is a driver is a driver; they all have to do pretty much the same things in the same order, BSD and Linux just express that a little differently. I've typically found that figuring out how to make the d*mn badly documented hardware behave is way harder than glueing it into your OS of choice :-) Scott -- === Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels Cambridge, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
clk0 interrupt accounting weirdness ???
Hi all, The attached thread (apologies for the volume of text, but it is all relevant) came up on freebsd-xircom last week. Jose Alcaide actually posted to -mobile on the same subject a week or so before, but got no response. We figure it's definitely nothing to do with the Xircom driver in particular and probably nothing to do with pccard, so I'm bouncing it to any interested kernel gurus. Essentially, the irq line to which clk0 interrupts are accounted (in the output from vmstat -i) changes when pccards are inserted/removed. The same effect has been seen with cards using the xe0 and ed0 drivers. Any ideas? Scott -- === Scott Mitchell | PGP Key ID |"If I can't have my coffee, I'm just Cambridge, England | 0x54B171B9 | like a dried up piece of roast goat" [EMAIL PROTECTED] | 0xAA775B8B | -- J. S. Bach. Hello, I have just purchased a Xircom RE-100BTX. It works fine, but I found something very strange. After booting the system (with no pccard inserted), "vmstat -i" shows: interrupt total rate clk0 irq0 718701 100 ... But, just after I insert the Xircom card and it is detected and enabled, another "vmstat -i" shows: interrupt total rate clk0 irq3 732248 110 (IRQ3 is the first available interrupt in my system, and it is assigned to the Xircom card by the pccardd daemon. I am running FreeBSD 3.4-RELEASE, no PAO.) After inserting the card, the clk0 interrupts are accounted to the interrupt level used by the Xircom card (I have tried other IRQ levels with the same result). The 100 interrupts/second generated by the timer are added to the interrupts generated by the Ethernet adapter. Since I don't have any other PCMCIA cards, I don't know whether this "problem" only happens with the xe driver or, on the contrary, it is a general problem of the FreeBSD's pccard driver. Did anybody find this same behavior? -- JMA --- José Mª Alcaide | mailto:[EMAIL PROTECTED] Universidad del País Vasco | mailto:[EMAIL PROTECTED] Dpto. de Electricidad y Electrónica | http://www.we.lc.ehu.es/~jose Facultad de Ciencias - Campus de Lejona | Tel.: +34-946012479 48940 Lejona (Vizcaya) - SPAIN | Fax: +34-946013071 --- "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein After inserting the card, the clk0 interrupts are accounted to the interrupt level used by the Xircom card (I have tried other IRQ levels with the same result). The 100 interrupts/second generated by the timer are added to the interrupts generated by the Ethernet adapter. Since I don't have any other PCMCIA cards, I don't know whether this "problem" only happens with the xe driver or, on the contrary, it is a general problem of the FreeBSD's pccard driver. Hmmm taking a quick look at my 'vmstat -i' output I see the same thing: clk0 irq10 2667404102 bunch of others deleted IRQ10 is the IRQ I hooked to my RealPort. I'll give the ed0 card I have at home a shot tonight. DocWilco On Tue, Jan 25, 2000 at 05:31:08PM +0100, ROGIER MULHUIJZEN wrote: After inserting the card, the clk0 interrupts are accounted to the interrupt level used by the Xircom card (I have tried other IRQ levels with the same result). The 100 interrupts/second generated by the timer are added to the interrupts generated by the Ethernet adapter. Since I don't have any other PCMCIA cards, I don't know whether this "problem" only happens with the xe driver or, on the contrary, it is a general problem of the FreeBSD's pccard driver. Hmmm taking a quick look at my 'vmstat -i' output I see the same thing: clk0 irq10 2667404102 bunch of others deleted IRQ10 is the IRQ I hooked to my RealPort. I'll give the ed0 card I have at home a shot tonight. Another data point: Script started on Wed Jan 26 21:18:22 2000 orac 78 ~ vmstat -i interrupt total rate clk0 irq3 23175 99 rtc0 irq8 29662 127 fdc0 irq6 10 wdc0 irq14 19348 atkbd0 irq1 4682 psm0 irq12 90 Total 55249 238 [xe0 inserted here] orac 79 ~ vmstat -i interrupt total rate clk0 irq10 33303 100 rtc0 irq8 42600 127 fdc0 irq6 10 wdc0 irq14 20886 atkbd0 irq1 5011 psm0 irq12 90 Total 78502 235 orac 80 ~ exit irq3 is where my pccard controller typically lives; irq10 is (of course) the line occupied by xe0. I'll be interested to see what happens with Rogier's ed0 (I should probably borrow a 3Com card from work and try the same thin
Re: Reading CIS from kernel?
On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote: In message [EMAIL PROTECTED] "David O'Brien" writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the newbusification of pccard stuff and I'd rather not have to fix any more drivers than I have to. I wish I had seen it sooner. The Xircom driver is one of the ones that my first attempt at newbusification would have broken... Warner Ugh. In that case, can someone back out Poul-Henning's changes to the if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it from working. At least that way only my code will be bogus :-) Believe me, I know it's ugly, but there's no getting around the fact that the driver needs to read the CIS, and right now there's no clean way to do that in -STABLE (is there?). Scott -- ======= Scott Mitchell | PGP Key ID | "Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines" [EMAIL PROTECTED] | 0xAA775B8B | -- Anon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Reading CIS from kernel?
On Wed, Jul 14, 1999 at 12:52:38AM -0600, Warner Losh wrote: In message 19990713182203.a68...@nuxi.com David O'Brien writes: : Since no one has repsonded to this querry, I will be un-staticizing these : so they will be available to drivers. No. Please don't. This is the first I've seen this. There will be another cis reading interface as part of the newbusification of pccard stuff and I'd rather not have to fix any more drivers than I have to. I wish I had seen it sooner. The Xircom driver is one of the ones that my first attempt at newbusification would have broken... Warner Ugh. In that case, can someone back out Poul-Henning's changes to the if_xe.c in the -STABLE tree? That's (I hope) the only thing stopping it from working. At least that way only my code will be bogus :-) Believe me, I know it's ugly, but there's no getting around the fact that the driver needs to read the CIS, and right now there's no clean way to do that in -STABLE (is there?). Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines s.mitch...@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Reading CIS from kernel?
Hi all, The Xircom ethernet driver needs to read/write PCCARD attribute memory from its probe routine, in order to identify the type of card and to beat brain-damaged CEM56 cards into shape :-) Currently this is done by way of 'fake' calls to read() and write() on the appropriate /dev/cardXX device. However, if we look at the version of the driver that David O'Brien has kindly committed to the repository (http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/pccard/if_xe.c) we see: === RCS file: /home/ncvs/src/sys/dev/pccard/if_xe.c,v retrieving revision 1.2 retrieving revision 1.3 diff -p -u -r1.2 -r1.3 --- src/sys/dev/pccard/if_xe.c 1999/05/14 04:18:24 1.2 +++ /home/ncvs/src/sys/dev/pccard/if_xe.c 1999/05/31 11:24:51 1.3 @@ -352,7 +352,11 @@ xe_memwrite(struct pccard_devinfo *devi, uios.uio_rw = UIO_WRITE; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]-d_write(makedev(CARD_MAJOR, devi-slt-slotnum), uios, 0); +#else + return (-1); +#endif } @@ -373,7 +377,11 @@ xe_memread(struct pccard_devinfo *devi, uios.uio_rw = UIO_READ; uios.uio_procp = 0; +#if 0 /* THIS IS BOGUS */ return cdevsw[CARD_MAJOR]-d_read(makedev(CARD_MAJOR, devi-slt-slotnum), uios, 0); +#else + return (-1); +#endif } Now I'll grant you that it probably *is* bogus, but when I first started writing the driver it was the least ugly solution proposed. So, since I can't do it that way anymore, are there any suggestions for an 'approved' way of reading/writing PCCARD attribute memory from inside the kernel? If it's just the use of cdevsw[] that's problematic, then making crdread() and crdwrite() (in /sys/pccard/pccard.c) non-static and calling them directly from the driver code would be an easy workaround. Alternatively, I could export pccard_mem and pccard_kmem from the same file and do the reads and writes myself, but that seems a bit dangerous. Any other approach would seem to involve duplicating more of the PCCARD code than I care to, expecially considering that it's all being redone in the newbus-ification of -CURRENT. I'd appreciate some advice from the powers-that-be as to what will and won't get stomped on here, as both David and I would like to see a *working* version of this code in the tree... Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines s.mitch...@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SMP and Celerons...
On Sat, Jun 19, 1999 at 04:57:25PM -0600, Warner Losh wrote: By broke, I mean that they don't scale well due to cache effects. I think it may just be a size thing, but it might also be a cache coherency protocol ineffeciencies as well. The articles I've seen show that for typical workloads, people with two celerons were getting in the 1.5x range, while people with PIIs were getting 1.8x or so. Warnr Warner, Don't suppose you have a URL handy for those articles? I'm contemplating building a dual-Celery box so it's probably good to know this stuff. Although, with the Celerons over here selling for around half the price of an equivalent P-II they'd have to scale real bad to put me off the idea :-) Even if the performance sucks, I'll have an otherwise well-specced box that I can upgrade to P-II's as I can afford it. Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines s.mitch...@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
