Blocked Delivery of email from sergeev@granch.ru
BLOCKED DELIVERY OF EMAIL FROM [EMAIL PROTECTED] Our email scanner has detected a VIRUS in an email destined for you. This email has been stopped. The sender will receive a notification of this message. This is ONLY a warning. You have not suffered any damage nor received any problem; You can safely ignore this email. You have been protected by the Inflex scanner http://pldaniels.com/inflex The virus scanner revealed... þ KAV for FreeBSD start 18.04.2002 19:05:45 Version 3.0 build 136 Last update: 12.04.2002, 53474 records. Command line: -Y -W /usr/local/inflex/tmp/inf_0418190592078/unpacked Profile (from 18.04.2002 19:05:17) /usr/local/avpbsd/avpBSD/defUnix.prf /usr/local/inflex/tmp/inf_0418190592078/unpacked/_headers_ archive: Mail /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile0 suspicion: Exploit.IFrame.FileDownload /usr/local/inflex/tmp/inf_0418190592078/unpacked/_CTI_.bat ok. /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile2 archive: Mail /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile2/cti.htm ok. Scan process completed. Result for all objects: Sector Objects : 0Known viruses : 0 Files : 4 Virus bodies : 0 Folders : 1 Disinfected : 0 Archives : 2 Deleted : 0 Packed : 0 Warnings : 0 Suspicious : 1 Speed (Kb/sec) : 49Corrupted : 0 Scan time : 00:00:02I/O Errors : 0 End. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Blocked Delivery of email from sergeev@granch.ru
BLOCKED DELIVERY OF EMAIL FROM [EMAIL PROTECTED] Our email scanner has detected a VIRUS in an email destined for you. This email has been stopped. The sender will receive a notification of this message. This is ONLY a warning. You have not suffered any damage nor received any problem; You can safely ignore this email. You have been protected by the Inflex scanner http://pldaniels.com/inflex The virus scanner revealed... þ KAV for FreeBSD start 18.04.2002 19:05:45 Version 3.0 build 136 Last update: 12.04.2002, 53474 records. Command line: -Y -W /usr/local/inflex/tmp/inf_0418190592078/unpacked Profile (from 18.04.2002 19:05:17) /usr/local/avpbsd/avpBSD/defUnix.prf /usr/local/inflex/tmp/inf_0418190592078/unpacked/_headers_ archive: Mail /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile0 suspicion: Exploit.IFrame.FileDownload /usr/local/inflex/tmp/inf_0418190592078/unpacked/_CTI_.bat ok. /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile2 archive: Mail /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile2/cti.htm ok. Scan process completed. Result for all objects: Sector Objects : 0Known viruses : 0 Files : 4 Virus bodies : 0 Folders : 1 Disinfected : 0 Archives : 2 Deleted : 0 Packed : 0 Warnings : 0 Suspicious : 1 Speed (Kb/sec) : 49Corrupted : 0 Scan time : 00:00:02I/O Errors : 0 End. BLOCKED DELIVERY OF EMAIL FROM [EMAIL PROTECTED] Our email scanner has detected a file type (or content) which we are not permitting through our systems. These namely include movies, executables and large pictures. Your email has been stopped. The intended sender will receive a notification of this message. This is ONLY a warning. You have not suffered any damage nor received any problem; You can safely ignore this email. You have been protected by the Inflex scanner http://pldaniels.com/inflex The files that were blocked are... MS-DOS executable (EXE), OS/2 or MS Windows End. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Blocked Delivery of email from sergeev@granch.ru
MailHub Virus Scanner [EMAIL PROTECTED] writes: BLOCKED DELIVERY OF EMAIL FROM [EMAIL PROTECTED] Our email scanner has detected a VIRUS in an email destined for you. This email has been stopped. The sender will receive a notification of this message. This is ONLY a warning. You have not suffered any damage nor received any problem; You can safely ignore this email. You have been protected by the Inflex scanner http://pldaniels.com/inflex The virus scanner revealed... þ KAV for FreeBSD start 18.04.2002 19:05:45 Version 3.0 build 136 Last update: 12.04.2002, 53474 records. Command line: -Y -W /usr/local/inflex/tmp/inf_0418190592078/unpacked Profile (from 18.04.2002 19:05:17) /usr/local/avpbsd/avpBSD/defUnix.prf /usr/local/inflex/tmp/inf_0418190592078/unpacked/_headers_archive: Mail /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile0suspicion: Exploit.IFrame.FileDownload /usr/local/inflex/tmp/inf_0418190592078/unpacked/_CTI_.batok. /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile2archive: Mail /usr/local/inflex/tmp/inf_0418190592078/unpacked/textfile2/cti.htmok. Scan process completed. Result for all objects: Sector Objects : 0Known viruses : 0 Files : 4 Virus bodies : 0 Folders : 1 Disinfected : 0 Archives : 2 Deleted : 0 Packed : 0 Warnings : 0 Suspicious : 1 Speed (Kb/sec) : 49Corrupted : 0 Scan time : 00:00:02I/O Errors : 0 End. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- 2147483647 Best Regards, -- Dmitry Nezhinsky [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Looking for pointers: loader, sysctl, kern.ipc.semmni co.
Sorry if this is a newbie question: I'm looking to tune (amongst others) kern.ipc.semmni; looking at the code (sys/kern/sysv_sem.c) the value seems pretty hardwired - proof against anything short of a kernel rebuild. The man page for loader(8) and tuning(7), there's a reasonably small set of tunable sysctls that are settable as the kernel loads. My question is: is this list definitive? - or does the loader perform some boot-time magic* to locate and set other sysctls? As well as (or instead of) a simple yes or no, I'd appreciate a pointer as to the right bit of the source tree to be looking through. Alas, it's about 20 years since I last looked at Forth :-( Cheers, jan * ok, some _more_ boottime magic -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 [EMAIL PROTECTED] New Freedom of Information Act: theirs, to yours. Happy now? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: make(1) command-line variables
On Sat, Apr 13, 2002 at 09:12:26PM +0400, Alex Semenyaka wrote:
Hi there,
On Sat, Apr 13, 2002 at 11:16:20AM -0400, Matthew Emmerton wrote:
.MAKEFLAGS
The environment variable MAKEFLAGS may contain anything
that
may be specified on make's command line. Its contents are
stored in make's .MAKEFLAGS variable.
That is wrong, .MAKEFLAGS does not contain anything.
It won't contain anything unless you set MAKEFLAGS in the calling
environment.
Argh! Sorry, that was my fault: MAKEFLASG (env var) will be copied to
.MAKEFLAGS (make's var) and it can contain anything. Absolutely correct -
here. But I've asked a little bit different question. Suppose, I wrote
make VAR=VAL # .MAKEFLAGS is empty
There is no way to trace this parameter inside Makefile. I mean you cannot
put something in your Makefile that will tell you 'for this build we have
value VAL assined to the variable VAR'. However you can easily do such
things with definitions of that style:
make -DVAR# .MAKEFLAGS is '-D VAR'
which logically should be equivalent to
make VAR=1# .MAKEFLAGS is empty again
Moreover, in the last case there is NO ANY MAKE'S VARIABLE containing VAR, see:
bash-2.05a$ make -DUUU -V .MAKEFLAGS
-D UUU -V .MAKEFLAGS
bash-2.05a$ make UUU=1 -V .MAKEFLAGS
-V .MAKEFLAGS
bash-2.05a$ make UUU=1 -dv -r | grep UUU
bash-2.05a$
Hope now I was more careful and clear... But sure I might miss sothing
again, so will wait for replys.
Heh, was looking at this NetBSD commitlog today looking for another
thing. They apparently have this bug fixed as well, in the step 3
below:
: revision 1.67
: date: 2001/06/01 20:33:37; author: sjg; state: Exp; lines: +42 -6
:
: A number of semi-related changes.
: 1. make -dx turns on DEBUG_SHELL which causes sh -x to be used where
:possible.
: 2. PrintOnError() is now called when make is stopping due to an error.
:This routine reports the curdir and the value of any variables listed
:in MAKE_PRINT_VAR_ON_ERROR.
: 3. Variables set via command line, are propagated to child-makes via
:MAKEFLAGS. This behaviour appears to be necessary for POSIX (according
:to the GNU folk anyway).
: 4. Do not reset MAKEFILE when reading .depend as this rather eliminates the
:usefulness of ${MAKEFILE}.
: 5. Added ${.newline} as a simple means of being able to include \n in the
:result of a :@ loop expansion.
: 6. Set ${MAKE_VERSION} if defined. Need to come up with a useful value.
:
: Reviewed: christos
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg33644/pgp0.pgp
Description: PGP signature
Re: Hardlinks...
Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. Actually, with minimal work in the rc.diskless* files, we have a very workable, large-scale system with / as Read-Only. In fact, only /dev and /var are read-write (well, in testing we also have a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp points are /var/tmp) One of these days I will want to write up some of what we did. It really is rather nice to have a whole cluster of machines sharing the same install and the boot server. -- Michael Sinz Worldgate Communications [EMAIL PROTECTED] A master's secrets are only as good as the master's ability to explain them to others. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bugs in FAT code
Hello everyone,
While trying to migrate some FAT32 filesystems to FFS, I encountered a
kernel trap 12 error. This happened on a Pentium II 233 and a K6-2 333MHz.
The fault happends when trying to do a 'ls q' on a mounted 40GB FAT32 disk,
connected to a Promise TX2 PCI IDE controller.
uname -a says:
--
FreeBSD sidious.ikuu.org 4.5-STABLE FreeBSD 4.5-STABLE #7: Thu Apr 18
17:13:54 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/SIDIOUS i386
--
The dmesg log is:
--
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.5-STABLE #7: Thu Apr 18 17:13:54 GMT 2002
[EMAIL PROTECTED]:/usr/src/sys/compile/SIDIOUS
Timecounter i8254 frequency 1193182 Hz
Timecounter TSC frequency 334092596 Hz
CPU: AMD-K6(tm) 3D processor (334.09-MHz 586-class CPU)
Origin = AuthenticAMD Id = 0x58c Stepping = 12
Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX
AMD Features=0x8800SYSCALL,3DNow!
real memory = 67108864 (65536K bytes)
avail memory = 62390272 (60928K bytes)
Preloaded elf kernel kernel at 0xc02f.
Preloaded userconfig_script /boot/kernel.conf at 0xc02f009c.
netsmb_dev: loaded
K6-family MTRR support enabled (2 registers)
Using $PIR table, 4 entries at 0xc00fd9f0
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge at device 1.0 on
pci0
pci1: PCI bus on pcib1
pci1: SiS 6326 SVGA controller at 0.0
isab0: VIA 82C586 PCI-ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: VIA 82C586 ATA33 controller port 0xd000-0xd00f at device 7.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: VIA 83C572 USB controller at 7.2 irq 11
chip1: VIA 82C586B ACPI interface at device 7.3 on pci0
rl0: RealTek 8139 10/100BaseTX port 0xd800-0xd8ff mem
0xe8804000-0xe88040ff irq 10 at device 8.0 on pci0
rl0: Ethernet address: 00:50:fc:39:8f:e5
miibus0: MII bus on rl0
rlphy0: RealTek internal media interface on miibus0
rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
atapci1: Promise TX2 ATA100 controller port
0xec00-0xec0f,0xe800-0xe803,0xe400-0xe407,0xe000-0xe003,0xdc00-0xdc07 mem
0xe880-0xe8803fff irq 12 at device 9.0 on pci0
ata2: at 0xdc00 on atapci1
ata3: at 0xe400 on atapci1
orm0: Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc9fff on isa0
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard irq 1 on atkbdc0
kbd0 at atkbd0
vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: System console at flags 0x100 on isa0
sc0: VGA 16 virtual consoles, flags=0x300
sio0: configured irq 4 not in bitmap of probed irqs 0
ad0: 4103MB ST34321A [8894/15/63] at ata0-master UDMA33
ad4: 39083MB Maxtor 4D040H2 [79408/16/63] at ata2-master UDMA100
ad5: 58644MB Maxtor 4W060H4 [119150/16/63] at ata2-slave UDMA100
ad6: 38182MB MAXTOR 4K040H2 [77578/16/63] at ata3-master UDMA100
ad7: 39083MB Maxtor 5T040H4 [79408/16/63] at ata3-slave UDMA100
Mounting root from ufs:/dev/ad0s1a
WARNING: / was not properly dismounted
--
The commands used were:
# mount -t msdos /dev/ad6s1 /mnt
# cd /mnt/Direct Connect
# ls q
Then, the machine bombs out with a Trap 12 error. The machine's DDB said:
--
kernel: type 12 trap, code = 0
Stopped at updatefats+0x37: andl 0(%esi,%edx,4),%eax
db
--
I compiled DDB and everything in, and analyzed the core dump. This gave:
# cd /sys/compile/SIDIOUS
# gdb -k kernel.debug /var/crash/vmcore.0
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-freebsd...
IdlePTD at phsyical address 0x0030f000
initial pcb at physical address 0x0028ab20
panicstr: from debugger
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xe09a7ffc
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01858d3
stack pointer = 0x10:0xc620ad04
frame pointer = 0x10:0xc620ad14
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 152 (ls)
interrupt mask = none
panic: from debugger
panic: from debugger
Uptime: 1m17s
dumping to dev #ad/0x20001, offset 131072
dump ata0: resetting devices .. done
64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40
39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15
14 13 12 11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at ../../kern/kern_shutdown.c:487
487 if (dumping++) {
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:487
#1 0xc014a2fb in boot
[FOLLOWUP] Bugs in FAT code
Hi once again, I just did some messing around myself, and gdb reveiled that pmp-pm_inusemap is in fact NULL... this would explain the panic. This is a bug all right, but it seems the FAT32 volume itself isn't that fine either. fsck_msdosfs chokes on it: -- ** /dev/ad6s1 backup doesn't compare to primary bootblock -- It does this for my other drives too, though... --Rink To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Hardlinks...
On Thu, Apr 18, 2002 at 11:18:30AM -0400, Michael Sinz wrote: Crist J. Clark wrote: On Mon, Apr 08, 2002 at 09:13:12PM -0700, Terry Lambert wrote: [snip] It's arguable that / and /usr themselves should be mounted read-only, It's not very practical to have / read-only on a truely multi-user (the only time this linking stuff is much of an issue) 4-STABLE system. The two main reasons being /etc/master.passwd, et al, and the problems with a read-only /dev. It takes extensive customizations and kludges to get this to work. Actually, with minimal work in the rc.diskless* files, we have a very workable, large-scale system with / as Read-Only. In fact, only /dev and /var are read-write (well, in testing we also have a /sewer for coredumps) /dev and /var are local RAM disks (and /tmp points are /var/tmp) It may be easier to fit it in with a diskless configuration. One of the problems is that in a normal (i.e. not diskless) stuff in /dev is used before you get at chance to mount something over /dev. And that may or may not be a problem. But the diskless stuff is run so early in the boot process, it seems like it should be easier to manage that. One of these days I will want to write up some of what we did. That would be interesting. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
naive i386 FreeBSD interrupt question
This was -stable- but it's really a hacker's question. I really am *not* much of an i386 weenie and I'll have to admit that I don't fully understand the interrupt mask scheme and I ran into a troubling problem. I was running some very extensive tests on a dual processor (but not SMP configured) system- I was in the middle of calling busdma_load from the isp driver when I got interrupted and blew up fielding an isp interrupt. Now- this shouldn't have happened. When I entered the isp driver, I'd called splcam- this should have blocked me from being interrupted. However, in calling busdma_load, I'd also called splsoftvm() (this is code copied, blindly, from other drivers). Now- if I was running on a 68020 or a Sparc or an Alpha, I would simply have assumed that the splsoftvm had (*smack*) forcibly lowered PIL. Oops. It was just for this reason that in SunOS all named spl calls were turned into s = splr(pritospl(device_interrupt_priority)); which would only raise (if needed) priority- never lower it. So- when I went to try and deduce what was going on for i386, I become a bit confused because, haha, that's right, all interrupts are separately maskable and have nothing really to do (I *think*- I'm paying the price for not really knowing i386 well enough) with a global processor priority level. So- what's the deal here? Why did a call to splsoftm *apparently* unmask the CAM device blockage such that I got interrupted when I thought I was blocked? A short RTFC is a fine answer- but if somebody could clue me in, that'd be nice. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Floppy device driver problem (with patch)
We've got a brand new Compaq ProLiant DL380 G2 machine but floppy drive
wasn't working at all with FreeBSD 4.x.
I found that there was a PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/21397
I got the following error messages:
Apr 16 16:57:48 /kernel: fdc0: direction bit not set
Apr 16 16:57:48 /kernel: fdc0: cmd 3 failed at out byte 1 of 3
Apr 16 16:57:48 /kernel: fdc0: direction bit not set
Apr 16 16:57:48 /kernel: fdc0: cmd 13 failed at out byte 1 of 4
Apr 16 16:57:48 /kernel: fdc0: Re-enable FIFO failed
Apr 16 16:57:50 /kernel: fdc0: direction bit not set
Apr 16 16:57:50 /kernel: fdc0: cmd 8 failed at out byte 1 of 1
Apr 16 16:57:50 /kernel: fdc0: sense intr err reading stat reg 0
-- 8 8 8 8
8 8 --
Apr 16 16:58:10 /kernel: fdc0: direction bit not set
Apr 16 16:58:10 /kernel: fdc0: cmd 8 failed at out byte 1 of 1
Apr 16 16:58:10 /kernel: fdc0: sense intr err reading stat reg 0
Apr 16 16:58:10 /kernel: fdc0: direction bit not set
Apr 16 16:58:10 /kernel: fdc0: cmd 7 failed at out byte 1 of 2
Apr 16 16:58:10 /kernel: fdc0: direction bit not set
Apr 16 16:58:10 /kernel: fdc0: cmd 3 failed at out byte 1 of 3
Apr 16 16:58:10 /kernel: fdc0: direction bit not set
Apr 16 16:58:10 /kernel: fdc0: cmd 13 failed at out byte 1 of 4
Apr 16 16:58:10 /kernel: fdc0: too many errors, not logging any more
I read src/sys/isa/fd.c and found out it was an ancient bug. Here is a
patch against 4.5-STABLE. Please note that 5.0-CURRENT has the same
problem. I will post the patch soon.
JK
--- sys/isa/fd.c.oldFri Apr 5 07:37:04 2002
+++ sys/isa/fd.cTue Apr 16 19:59:03 2002
-424,13 +424,15
return fdc_err(fdc, Enable FIFO failed\n);
/* If command is invalid, return */
- j = 10;
+ j = FDSTS_TIMEOUT;
while ((i = fdsts_rd(fdc) (NE7_DIO | NE7_RQM))
- != NE7_RQM j-- 0)
+ != NE7_RQM j-- 0) {
if (i == (NE7_DIO | NE7_RQM)) {
fdc_reset(fdc);
return FD_FAILED;
}
+ DELAY(1);
+ }
if (j0 ||
fd_cmd(fdc, 3,
0, (fifo_threshold - 1) 0xf, 0, 0) 0) {
-1296,11 +1298,13
int
in_fdc(struct fdc_data *fdc)
{
- int i, j = 10;
+ int i, j = FDSTS_TIMEOUT;
while ((i = fdsts_rd(fdc) (NE7_DIO|NE7_RQM))
- != (NE7_DIO|NE7_RQM) j-- 0)
+ != (NE7_DIO|NE7_RQM) j-- 0) {
if (i == NE7_RQM)
return fdc_err(fdc, ready for output in input\n);
+ DELAY(1);
+ }
if (j = 0)
return fdc_err(fdc, bootverbose? input ready timeout\n: 0);
#ifdef FDC_DEBUG
-1318,11 +1322,13
static int
fd_in(struct fdc_data *fdc, int *ptr)
{
- int i, j = 10;
+ int i, j = FDSTS_TIMEOUT;
while ((i = fdsts_rd(fdc) (NE7_DIO|NE7_RQM))
- != (NE7_DIO|NE7_RQM) j-- 0)
+ != (NE7_DIO|NE7_RQM) j-- 0) {
if (i == NE7_RQM)
return fdc_err(fdc, ready for output in input\n);
+ DELAY(1);
+ }
if (j = 0)
return fdc_err(fdc, bootverbose? input ready timeout\n: 0);
#ifdef FDC_DEBUG
-1344,13 +1350,15
int i;
/* Check that the direction bit is set */
- i = 10;
- while ((fdsts_rd(fdc) NE7_DIO) i-- 0);
+ i = FDSTS_TIMEOUT;
+ while ((fdsts_rd(fdc) NE7_DIO) i-- 0)
+ DELAY(1);
if (i = 0) return fdc_err(fdc, direction bit not set\n);
/* Check that the floppy controller is ready for a command */
- i = 10;
- while ((fdsts_rd(fdc) NE7_RQM) == 0 i-- 0);
+ i = FDSTS_TIMEOUT;
+ while ((fdsts_rd(fdc) NE7_RQM) == 0 i-- 0)
+ DELAY(1);
if (i = 0)
return fdc_err(fdc, bootverbose? output ready timeout\n: 0);
--- sys/isa/fdreg.h.old Thu Jan 6 02:13:54 2000
+++ sys/isa/fdreg.h Tue Apr 16 19:54:28 2002
-72,3 +72,4
#defineFDI_DCHG0x80/* diskette has been changed */
/* requires drive and motor being selected */
/* is cleared by any step pulse to drive */
+#define FDSTS_TIMEOUT 200 /* fdsts_rd() timeout */
Re: make(1) command-line variables
Hi there, On Thu, Apr 18, 2002 at 05:31:01PM +0300, Ruslan Ermilov wrote: make VAR=VAL # .MAKEFLAGS is empty make -DVAR # .MAKEFLAGS is '-D VAR' Heh, was looking at this NetBSD commitlog today looking for another thing. They apparently have this bug fixed as well, in the step 3 below: :: 3. Variables set via command line, are propagated to child-makes via ::MAKEFLAGS. This behaviour appears to be necessary for POSIX (according ::to the GNU folk anyway). So what will The Right Thing be: - to take ``make'' from NetBSD - to transfer corresponding changes from NetBSD - to re-make my patch (to store the command line variables in MAKEFLAGS, not in the new variable)? Of course, I cannot perform first choice but I can do second or third ones. SY, Alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: naive i386 FreeBSD interrupt question
On Thu, Apr 18, 2002 at 12:27:33 -0700, Matthew Jacob wrote: This was -stable- but it's really a hacker's question. I really am *not* much of an i386 weenie and I'll have to admit that I don't fully understand the interrupt mask scheme and I ran into a troubling problem. I was running some very extensive tests on a dual processor (but not SMP configured) system- I was in the middle of calling busdma_load from the isp driver when I got interrupted and blew up fielding an isp interrupt. Now- this shouldn't have happened. When I entered the isp driver, I'd called splcam- this should have blocked me from being interrupted. However, in calling busdma_load, I'd also called splsoftvm() (this is code copied, blindly, from other drivers). Now- if I was running on a 68020 or a Sparc or an Alpha, I would simply have assumed that the splsoftvm had (*smack*) forcibly lowered PIL. Oops. It was just for this reason that in SunOS all named spl calls were turned into s = splr(pritospl(device_interrupt_priority)); which would only raise (if needed) priority- never lower it. So- when I went to try and deduce what was going on for i386, I become a bit confused because, haha, that's right, all interrupts are separately maskable and have nothing really to do (I *think*- I'm paying the price for not really knowing i386 well enough) with a global processor priority level. So- what's the deal here? Why did a call to splsoftm *apparently* unmask the CAM device blockage such that I got interrupted when I thought I was blocked? A short RTFC is a fine answer- but if somebody could clue me in, that'd be nice. I'm no expert on this, but from sys/i386/isa/ipl_funcs.c, it looks like both splsoftvm() and splcam() are |= masks, so they should be in addition to whatever mask you had before. So it looks like things should work as you expected. So why didn't it work as you expected? I dunno. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Looking for pointers: loader, sysctl, kern.ipc.semmni co.
On Thu, 18 Apr 2002, Jan Grant wrote: ... Sorry if this is a newbie question: I'm looking to tune (amongst others) kern.ipc.semmni; looking at the code (sys/kern/sysv_sem.c) the value seems pretty hardwired - proof against anything short of a kernel rebuild. Take a closer look. Esp. in seminit() starting at line 162 ( -current ). You'll see a bunch of TUNABLE_INT_FETCH(...). These are tunable during loader(8) time. Bye! Michael Reifenberger ^.*Plaut.*$, IT, R/3 Basis, GPS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Floppy device driver problem (with patch)
Here is the patch against 5.0-CURRENT. Please note that it wasn't
tested. ;-)
Thanks,
JK
--- sys/isa/fd.c.oldTue Apr 2 13:29:43 2002
+++ sys/isa/fd.cThu Apr 18 17:42:03 2002
-563,13 +563,15
return fdc_err(fdc, Enable FIFO failed\n);
/* If command is invalid, return */
- j = 10;
+ j = FDSTS_TIMEOUT;
while ((i = fdsts_rd(fdc) (NE7_DIO | NE7_RQM))
- != NE7_RQM j-- 0)
+ != NE7_RQM j-- 0) {
if (i == (NE7_DIO | NE7_RQM)) {
fdc_reset(fdc);
return FD_FAILED;
}
+ DELAY(1);
+ }
if (j0 ||
fd_cmd(fdc, 3,
0, (fifo_threshold - 1) 0xf, 0, 0) 0) {
-1473,11 +1475,13
static int
fd_in(struct fdc_data *fdc, int *ptr)
{
- int i, j = 10;
+ int i, j = FDSTS_TIMEOUT;
while ((i = fdsts_rd(fdc) (NE7_DIO|NE7_RQM))
- != (NE7_DIO|NE7_RQM) j-- 0)
+ != (NE7_DIO|NE7_RQM) j-- 0) {
if (i == NE7_RQM)
return fdc_err(fdc, ready for output in input\n);
+ DELAY(1);
+ }
if (j = 0)
return fdc_err(fdc, bootverbose? input ready timeout\n: 0);
#ifdef FDC_DEBUG
-1499,13 +1503,15
int i;
/* Check that the direction bit is set */
- i = 10;
- while ((fdsts_rd(fdc) NE7_DIO) i-- 0);
+ i = FDSTS_TIMEOUT;
+ while ((fdsts_rd(fdc) NE7_DIO) i-- 0)
+ DELAY(1);
if (i = 0) return fdc_err(fdc, direction bit not set\n);
/* Check that the floppy controller is ready for a command */
- i = 10;
- while ((fdsts_rd(fdc) NE7_RQM) == 0 i-- 0);
+ i = FDSTS_TIMEOUT;
+ while ((fdsts_rd(fdc) NE7_RQM) == 0 i-- 0)
+ DELAY(1);
if (i = 0)
return fdc_err(fdc, bootverbose? output ready timeout\n: 0);
--- sys/isa/fdreg.h.old Sat Dec 15 14:07:58 2001
+++ sys/isa/fdreg.h Thu Apr 18 17:42:42 2002
-69,3 +69,4
#defineFDI_DCHG0x80/* diskette has been changed */
/* requires drive and motor being selected */
/* is cleared by any step pulse to drive */
+#defineFDSTS_TIMEOUT 200 /* fdsts_rd() timeout */
Non-interactive installation (with patch, of course)
Can we let sysinstall sanitize geometry while non-interactive
installation? This patch can be applied on src/release of 4.5-STABLE or
src/usr.sbin of 5.0-CURRENT.
Sorry for the whining but recent acquisition of Compaq ProLiant DL380 G2
made me do it. :-(
Thanks,
JK
--- sysinstall/disks.c Thu Apr 4 03:39:39 2002
+++ sysinstall/disks.c.new Thu Apr 18 18:42:29 2002
-866,6 +866,21
d-bios_hd = strtol(cp + 1, cp, 0);
d-bios_sect = strtol(cp + 1, 0, 0);
}
+#ifndef PC98
+else if (d-bios_cyl 65536 || d-bios_hd 256 || d-bios_sect = 64) {
+ dialog_clear_norefresh();
+ msgConfirm(WARNING: A geometry of %ld/%ld/%ld for %s is incorrect. Using\n
+ a more likely geometry. If this geometry is incorrect or you\n
+ are unsure as to whether or not it's correct, please stop here,\n
+ set ``geometry'' at diskPartitionEditor function, and restart.\n\n
+ Remember: you need to enter whatever your BIOS thinks the\n
+ geometry is! For IDE, it's what you were told in the BIOS\n
+ setup. For SCSI, it's the translation mode your controller is\n
+ using. Do NOT use a ``physical geometry''.,
+ d-bios_cyl, d-bios_hd, d-bios_sect, d-name);
+ Sanitize_Bios_Geom(d);
+}
+#endif
cp = variable_get(VAR_PARTITION);
if (cp) {
[no subject]
listers, I have a old puter DIGITAL CELEBRIS XL5133 / p133dual ( not the alpha upgrade ) which is being used for a gateway machine, I have yet to revert back to using Freebsd due to a minor SCSI CD problem, I have tried to Install FreeBSD4.5rel on this to no avail. Due to the fact that FreeBSD installer would not detect my CDROM or would often try to ( resetting all SCSI devices ), Yes i could install FreeBSD using another puter and another CDROM. ( in case there are some wise crack monkeys around ) however I only have this problem with FreeBSD. OpenBSD, ( hold the flame ) and Linux distros such as Redhat and Slackware give me no such problems :) if anyone could help me with my problem siop0 at pci0 dev 1 function 0 Symbios Logic 53c810 rev 0x02: irq 11, siop0: scsi bus reset scsibus0 at siop0: 8 targets cd0 at scsibus0 targ 6 lun 0: TOSHIBA, CD-ROM XM-5301TA, 1895 SCSI2 5/cdrom removable siop0: target 6 now using 8 bit async xfers thank you listed below is my dmesg from :) my current OS running on the box PS. really need to get SMP support on this box $ dmesg OpenBSD 3.0-stable (ELENCHUS) #5: Wed Apr 17 06:18:17 GMT 2002 root@stupid:/usr/src/sys/arch/i386/compile/ELENCHUS cpu0: F00F bug workaround installed cpu0: Intel Pentium (P54C) (GenuineIntel 586-class) 114 MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,APIC real mem = 83472384 (81516K) avail mem = 71962624 (70276K) using 1044 buffers containing 4276224 bytes (4176K) of memory mainbus0 (root) bios0 at mainbus0: AT/286+(07) BIOS, date 11/30/95, BIOS32 rev. 0 @ 0xfbdcf apm0 at bios0: Power Management spec V1.1 apm0: AC unknown, battery charge unknown, estimated 0:00 hours pcibios0 at bios0: rev. 2.1 @ 0xfbc90/0x1270 pcibios0: PCI BIOS has 4 Interrupt Routing table entries pcibios0: PCI Exclusive IRQs: 9 10 11 15 pcibios0: no compatible PCI ICU found pcibios0: Warning, unable to fix up PCI interrupt routing pcibios0: PCI bus #0 is the last bus bios0: ROM list: 0xc/0x8000 0xc8000/0x4000 pci0 at mainbus0 bus 0: configuration mode 2 (bios) pchb0 at pci0 dev 0 function 0 Intel 82434LX/NX PCI/Cache/DRAM rev 0x11 siop0 at pci0 dev 1 function 0 Symbios Logic 53c810 rev 0x02: irq 11, siop0: scsi bus reset scsibus0 at siop0: 8 targets cd0 at scsibus0 targ 6 lun 0: TOSHIBA, CD-ROM XM-5301TA, 1895 SCSI2 5/cdrom removable siop0: target 6 now using 8 bit async xfers pcib0 at pci0 dev 2 function 0 Intel 82378IB PCI-ISA rev 0x88 vga1 at pci0 dev 6 function 0 Matrox MGA Millenium 2064W (Storm) rev 0x01 wsdisplay0 at vga1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) xl0 at pci0 dev 7 function 0 3Com 3c905 100Base-TX rev 0x00: irq 10 address 00:a0:24:e0:48:36 nsphy0 at xl0 phy 24: DP83840 10/100 media interface, rev. 0 rl0 at pci0 dev 8 function 0 Realtek 8139 rev 0x10: irq 15 address 00:c0:26:6f:51:ea rlphy0 at rl0 phy 0: RTL internal phy isa0 at pcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 wdc0 at isa0 port 0x1f0/8 irq 14 wd0 at wdc0 channel 0 drive 0: QUANTUM FIREBALL CR4.3A wd0: 16-sector PIO, LBA, 4110MB, 14848 cyl, 9 head, 63 sec, 8418816 sectors wd0(wdc0:0:0): using BIOS timings pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker sysbeep0 at pcppi0 lpt0 at isa0 port 0x378/4 irq 7 npx0 at isa0 port 0xf0/16: using exception 16 pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec biomask 4840 netmask cc40 ttymask ccc2 pctr: 586-class performance counters and user-level cycle counter enabled dkcsum: wd0 matched BIOS disk 80 root on wd0a rootdev=0x0 rrootdev=0x300 rawdev=0x302 $ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
updated install files for 4.5-R after security patches?
I installed 4.5-RELEASE the other day, and then this zlib security advisory came out and I got to wondering.. are the install files for 4.5-RELEASE updated after patches are put into RELENG_4_5? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
