ATAng lockups (Re: geom<->ata forever cycle)
Sat, Nov 22, 2003 at 13:08:10, netch (Valentin Nechayev) wrote about "geom<->ata
forever cycle":
VN> 5.1-current of 2003-11-20 hangs during kernel initialization with forever
VN> cycle around geom partitioning detection and ATA read failure.
VN> Message rate is too fast to record, no stopping is available, no serial
VN> console.
VN> Previous 5-current on this machine was of 2003-05-23.
VN> How to diagnose?
Well, I restricted time interval to between 2003-08-18 and 2003-08-25, so it is
ATAng. Also tested 2003-11-20 and 2003-10-06 with the same result.
Different poses were seen:
- forever cycle around GEOM detecting
- simple lockup
- panic("initiate_write_inodeblock_ufs1: already started")
- another kinds of panic
and all have common sign - impossibility of driver to dig itself out of
lockup (switch to PIO, reset bus, etc.)
Dirty fix works to set hw.ata.ata_dma=0 in loader; moreover, `atacontrol
mode 1 udma100 -' doesn't cause problems, but `atacontrol mode 0 udma33 -'
drops system to broken state in a few minutes.
Please say how to dig this problem.
Full verbose dmesg.boot (from 2003-08-18 kernel) and config (unchanged)
was put in previous letters and can be resent personally.
Entries, bound with ATA, in first problematic (2003-08-25) dmesg.boot:
pcib0: at pcibus 0 on motherboard
atapci0: port 0xf000-0xf00f at device 31.1 on pci0
ata0: pre reset mask=03 ostat0=50 ostat2=00
ata0-master: ATAPI 00 00
ata0-slave: ATAPI 14 eb
ata0: after reset mask=03 stat0=50 stat1=00
ata0-master: ATA 01 a5
ata0: devices=09
ata0: at 0x1f0 irq 14 on atapci0
ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin
ata0-master: pio=0x0c wdma=0x22 udma=0x44 cable=40pin
ad0: setting PIO4 on Intel ICH2 chip
ad0: ATA-4 disk at ata0-master
ad0: 14664MB (30033360 sectors), 29795 C, 16 H, 63 S, 512 B
ad0: 16 secs/int, 1 depth queue, PIO4
acd0: setting PIO4 on Intel ICH2 chip
acd0: CDROM drive at ata0 as slave
acd0: read 6890KB/s (6890KB/s), 128KB buffer, PIO4
(remind that it is with hw.ata.ata_dma=0)
-netch-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: geom<->ata forever cycle
Sat, Nov 22, 2003 at 05:45:09, nickh wrote about "Re: geom<->ata forever cycle": > Personally I dont think this is GEOM related. I had a drive start doing Yes, it is ATAng related, AFAIS, but triggers GEOM forever cycle. > this to me (happens often as I work in a large datacenter) and the drive is > about to die. What brand drive is it and how old is it? You may waanna > look into replacing the drive if you have that option. I had one tonight > that did that to me, swap the drive, fixed. System has IBM DJNA-351520 and IBM IC35L040AVER07. They are alive and good. All other systems, including Win98, RedHat 8.0, FreeBSD 4.9 and FreeBSD-5.1 of May 2003, works well with these drivers. Hence, only fresh -current is broken. Full dmesg.boot of oldest -current follows. Copyright (c) 1992-2003 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 5.1-BETA-20030523 #2: Sun May 25 00:28:30 EEST 2003 root@:/var/obj/var/HEAD/src/sys/nn15 Preloaded elf kernel "/boot/kernel/kernel" at 0xc044c000. Preloaded elf module "/boot/modules/if_rl.ko" at 0xc044c1f4. Preloaded elf module "/boot/modules/miibus.ko" at 0xc044c2a0. Calibrating clock(s) ... i8254 clock: 1193010 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz Calibrating TSC clock ... TSC clock: 799435869 Hz Timecounter "TSC" frequency 799435869 Hz CPU: Intel Celeron (799.44-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 268369920 (255 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00473000 - 0x0fb31fff, 258732032 bytes (63167 pages) avail memory = 255709184 (243 MB) bios32: Found BIOS32 Service Directory header at 0xc00fad00 bios32: Entry = 0xfb190 (c00fb190) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xb1c0 pnpbios: Found PnP BIOS data at 0xc00fbbb0 pnpbios: Entry = f:bbe0 Rev = 1.0 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00 00 01 80 00 05 02 07 01 00 01 1a 01 00 01 23 01 00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01 07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01 VESA: 33 mode(s) found VESA: v3.0, 8192k memory, flags:0x1, mode table:0xc03ac7c2 (122) VESA: NVidia VESA: NVidia Corporation Riva TNT Chip Rev B1 npx0: on motherboard npx0: INT 16 interface pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Using $PIR table, 10 entries at 0xc00fded0 PCI-Only Interrupts: 5 9 11 Location Bus Device Pin Link IRQs slot 1 02A 0x60 3 4 5 7 9 10 11 14 15 slot 1 02B 0x61 3 4 5 7 9 10 11 14 15 slot 1 02C 0x62 3 4 5 7 9 10 11 14 15 slot 1 02D 0x63 3 4 5 7 9 10 11 14 15 slot 2 28A 0x68 3 4 5 7 9 10 11 14 15 slot 2 28B 0x69 3 4 5 7 9 10 11 14 15 slot 2 28C 0x6a 3 4 5 7 9 10 11 14 15 slot 2 28D 0x6b 3 4 5 7 9 10 11 14 15 slot 3 20A 0x60 3 4 5 7 9 10 11 14 15 slot 3 20B 0x61 3 4 5 7 9 10 11 14 15 slot 3 20C 0x62 3 4 5 7 9 10 11 14 15 slot 3 20D 0x63 3 4 5 7 9 10 11 14 15 slot 4 21A 0x61 3 4 5 7 9 10 11 14 15 slot 4 21B 0x62 3 4 5 7 9 10 11 14 15 slot 4 21C 0x63 3 4 5 7 9 10 11 14 15 slot 4 21D 0x60 3 4 5 7 9 10 11 14 15 slot 5 26A 0x62 3 4 5 7 9 10 11 14 15 slot 5 26B 0x63 3 4 5 7 9 10 11 14 15 slot 5 26C 0x60 3 4 5 7 9 10 11 14 15 slot 5 26D 0x61 3 4 5 7 9 10 11 14 15 slot 6 27A 0x63 3 4 5 7 9 10 11 14 15 slot 6 27B 0x60 3 4 5 7 9 10 11 14 15 slot 6 27C 0x61 3 4 5 7 9 10 11 14 15 slot 6 27D 0x62 3 4 5 7 9 10 11 14 15 slot 7 29A 0x61 3 4 5 7 9 10 11 14 15 slot 7 29B 0x62 3 4 5 7 9 10 11 14 15 slot 7 29C 0x63 3 4 5 7 9 10 11 14 15 slot 7 29D 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10A 0x62 3 4 5 7 9 10 11 14 15 slot 8 2 10B 0x63 3 4 5 7 9 10 11 14 15 slot 8 2 10C 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10D 0x61 3 4 5 7 9 10 11 14 15 embedded0 31A 0x60 3 4 5 7 9 10 11 14 15 embedded0 31B 0x61 3 4 5 7 9 10 11 14 15 embedded0 31C 0x6b 3 4 5 7 9 10 11 14 15 embedded0 31D 0x63 3 4 5 7 9 10 11 14 15 embedded01A 0x60 3 4 5 7 9 10 11 14 15 embedded01B 0x61 3 4 5 7 9 10 11 14 15 embedded01C 0x62 3 4 5 7 9
geom<->ata forever cycle
5.1-current of 2003-11-20 hangs during kernel initialization with forever cycle around geom partitioning detection and ATA read failure. Message rate is too fast to record, no stopping is available, no serial console. Previous 5-current on this machine was of 2003-05-23. How to diagnose? dmesg of May's current says: start_init: trying /sbin/init ad0: UDMA ICRC error cmd=read fsbn 4397730 of 4397730-4397857 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569 retrying ad0: UDMA ICRC error cmd=read fsbn 4398442 of 4398442-4398569ad0: success settin g PIO4 on Intel ICH2 chip falling back to PIO mode Main FreeBSD here is 4.9-release which doesn't complaint to crc errors. Kernel config wasn't changed: machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident nn15 maxusers0 #To statically compile in device wiring instead of /boot/device.hints hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options SCHED_4BSD options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support #optionsUFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev # Debugging for use in -current options DDB #Enable the kernel debugger options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, required by INVARIANTS options WITNESS #Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN#Don't run witness on spinlocks for speed device isa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID #Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device ether device loop# Network loopback device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter device speaker #Play IBM BASIC-style noises out your speaker # To include support for VGA VESA video modes options VESA # Turn on extra debugging checks and output for VESA support. options VESA_DEBUG # Enable i386 a.out binary support options COMPAT_AOUT # Enable the linux-like proc filesystem support (requires COMPAT_LINUX # and PSEUDOFS) options COMPAT_LINUX options LINPROCFS options MSGBUF_SIZE=131072 #options
Re: UFS file system problem in either stable or current
Wed, Oct 22, 2003 at 03:14:33, strick (Dan Strick) wrote about "UFS file system problem in either stable or current": DS> There seems to be an inconsistency between release 4.9-RC and 5.1 ufs DS> support. If I fsck the same ufs (type 1 of course) file system on DS> both releases, each claims that the other has left incorrect DS> summary data in the superblock. Presumably only one can be correct. DS> I just don't know which to blame. Does this require explicit fsck? I have dual-booting between 4.9-release (and all previous 4.* releases earlier) and 5.1 (of 20030526) with shared disks and boot checking required in fstab; sometimes one of them crash and forced checking is made; neither 4.* nor 5.1 claims superblock is bad. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dualbooting STABLE & CURRENT
Sat, Nov 01, 2003 at 20:38:36, s.wingate (Steve Wingate) wrote about "Re: Dualbooting STABLE & CURRENT": > >> I don't like the sound of that. I'll just stick with STABLE until 5.x is > >> really ready. >> -STABLE will have the same problem since its in boot0 and the BIOS, not >> the OS on the partition its trying to boot. SW> Actually STABLE will have no problems as it's been running on this box for SW> over a year. You have working STABLE on first disk, not on second. Well, please show fdisk output for both disks. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall's fdisk/disklabel should be improved
Wed, Oct 29, 2003 at 16:43:12, q (Ulrich Spoerlein) wrote about "Re: Sysinstall's fdisk/disklabel should be improved": >> It is NOT useless. Why do you think it is? Perhaps you don't relize >> that some BIOS's wont boot from a hard disk that isn't partitioned to >> agree with the specifications of the PeeCee. If you want to treat your >> PC as a Sun, don't -- buy a Sun, FreeBSD runs on that too. US> What exactly do you mean by "PC Specification"? I'm not trying to make a US> "dangerously dedicated" disk. I just don't need a spare 63 sectors for US> DOS-compatibility. And leaving the first 63 sectors untouched is a US> DOS-ism, not a PC-ism. Well, "dangerously dedicated" is name of partitioning mode which doesn't leave one track for dos PT and MBR switcher. It's just name. If you doesn't like this name, rename it in your mind. US> The BIOS' only job is to load the MBR (sector 0) which will then read US> and check the partition table and load the first sector of the 'active' US> partition into memory and pass execution to it. In real, BIOS can read master PT and even BPB on FAT to found which geometry (normal/ECHS/LBA-assist) should be reported. US> Therefore I created a big partition from sector 1 to the last sector US> with fdisk from the LiveCD. After writing the partition table I had to US> reboot sysinstall because it didn't recognise the partition layout has US> changed. So could someone be so kind to teach sysinstall a 'reset' US> button which will re-read the partition table and the disklabel info? It should be done automatically unless there are opened/mounted partitions on this disk. If you don't see changes, check whether you really asked to write changes immediately. Otherwise, they are delayed until commit phase. US> PS: I have a Sparcstation 20 and a b0rken Ultra1. None of them run FreeBSD. Do you consider this as a bug? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall's fdisk/disklabel should be improved
Sun, Oct 26, 2003 at 18:58:52, q (Ulrich Spoerlein) wrote about "Sysinstall's fdisk/disklabel should be improved": US> First of all, the Partition Editor has the 'A' option to use all of the US> available HDD space. It creates a DOS-compatible slice (starting at US> sector 63 and ending on cylinder boundary). This is completely useless US> on servers No, even on servers one may use only 6 data partitions or less, as to fit in one bsdlabel. US> and the help menu says that sysinstall will ask if it should US> create a DOS-compatible slice or not. However no such question is ever US> asked. I think help page should be fixed, but not fdisk code. US> Creating the slice manually, specifying the complete disk as 'size' will US> also leave the start and end of the disk unpartitioned (again, no US> question is ever asked). First track is leaved for compatibility with DOS-styled scheme. It is required for many BIOSes which want to determine provided geometry by reading PT. Some last part which can't fit in cylinder in declared geometry, rest unused. It is feature of DOS compatibility mode and there is no need to warn it. US> Ok, then the solution would be to drop to a shell and run fdisk by hand. US> However there is no fdisk/disklabel/newfs in that shell. Even 'ls' is US> not found. Running the LiveCD will give you a working fdisk/disklabel US> but the man-pages are not useable (manpath.config can't be found). US> Succeding in sliceing/partitioning without man-pages will still require US> to reboot sysinstall, because it doesn't re-read the partition/slice US> table but uses the in-memory table instead (I didn't find an option to US> re-read this information from disk) Does you say for 4.x or 5.x? Behavior you said is for 4.x. US> Please consider this, right now sysinstall is a tool which can only be US> used if you know all of it's bugs. IMHO even the OpenBSD installer is US> sometimes more elegant than sysinstall. US> Really brave souls should take a look at this list: US> http://www.freebsd.org/cgi/query-pr-summary.cgi?text=sysinstall sysinstall is ugly, but all you said for it doesn't matter, IMHO. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with sysinstall
Wed, Oct 29, 2003 at 05:44:44, sem (Sergey Matveychuk) wrote about "problems with sysinstall": SM> The first one: when I install -current on disk where WinXP on first SM> slice, sysinstall brakes WinXP boot complete. I got 'Missing operation SM> system' everytime. Even I've tried 'fixboot' and reinstall WinXP. SM> Helps only 'dd if=/dev/zero of=/dev/ad0 count=100' and reinstall WinXP SM> on clean disk. It can be better reported if you show here 1) 0th block of disk (where MBR and master PT resides) 2) full PT listing, with both standard fdisk and linux fdisk (from ports) and both of them before installing FreeBSD (when XP works) and after (when is already broken). SM> When I've installed first -current on first slice and second -current on SM> second slice I got booting only first one. I use grub and either I set SM> root(hd1,0) or root(hd1,1) (yes, it's a second disk) and 'chainloader SM> +1' and 'boot' I've got always first -current boot. Looks like problem SM> with boot sector where hardcoded booting from first slice (?). Yes, this is tied to algorithm of boot1. On first step, it founds first *active* BSD partition in master PT. If didn't find any, it tries to find BSD partition in any state (inactive, due to first step failure). When found, records its number and starts boot2. Boot switcher, called boot0 (/boot/boot0) or BootEasy (in sysinstall), changes active partition flag (see boot0cfg(8)). When you use GRUB to call chainloader, it will start boot1 with the described result. To select boots using GRUB, use UFS1 (GRUB can't understand UFS2), with "root (hd0,1); boot /boot/loader", or use boot0. SM> The second: when I've tried to save results from Fdisk or Label menu SM> I've got the message: 'ERROR: Unable to write data to disk ad0!' SM> Why? I can change slices and partitions only when I boot from CD-ROM. Current GEOM implementation is too restrictive and doesn't allow any write to disk which has opened slices/partitions. phk@ promised change of this as soon as someone gives working implementation. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with sysinstall
Wed, Oct 29, 2003 at 17:32:29, dwhite (Doug White) wrote about "Re: problems with sysinstall": >> Well, I understand it for slices. But why I can't create new partition >> in exist slice and newfs it? It was OK in -stable. DW> yes, this is a change to -current. It is for your own safety. Don't protect me when I didn't ask for it. FYI, phk@ said here some time ago how to remove this protection, and said that this nursery protection is in effect only until someone implements better algorithm. -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Way forward with BIND 8
Fri, Jun 06, 2003 at 03:01:02, DougB wrote about "Re: Way forward with BIND 8": > >> FYI, for those wondering why I'm not considering BIND 9 for import, please > >> see http://people.freebsd.org/~dougb/whybind8.html Among other things: standard resolver is waaay(tm) old. Even keeping with BIND8, it is old. At least, it isn't thread-safe; this is too ugly for 5.*. Unlike IRS code (gethostby*()), its upgrading to thread safe version is conceptually easy. I've created and successfully tested patch to upgrade it to 8.3.4 version, losing only res_*update() and RES_INSECURE*; it was very simple, and a person more informed in its specifics including KAME hacks can do it better. (ftp://segfault.kiev.ua/pub/freebsd/newresolv for someone wanting to see it. I should repeast that this attempt may be too lame and forgetting some principal moments, but it was successfully tested on real load for a long time.) -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Libthr stable enough for testing
Fri, May 30, 2003 at 17:38:04, larse (Lars Eggert) wrote about "Re: Libthr stable enough for testing": LE> I tried, but the following is a surefire way to freeze my SMP box solid LE> at the moment (with today's libthr): SCHED_ULE or SCHED_4BSD? -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 5.1-BETA2 boot up messages
Fri, May 30, 2003 at 18:53:16, segr (Stephane Raimbault) wrote about "FreeBSD 5.1-BETA2 boot up messages": SR> I just noticed that when I boot up in FreeBSD 5.1-BETA2 I get a whole bunch of SR> messages fly by the screen (see below for errors from /var/log/messages). SR> Does anyone know what is causing this and if it's normal in BETA2? You may reproduce it saying 'sysctl sysctl.debug' as root. Check syntax of your /etc/sysctl.conf. Sometimes weird entries in it caused such effect. SR> May 30 18:26:13 wks1 kernel: 873 ac97rate RW *Handler Int SR> May 30 18:26:13 wks1 kernel: 851 acpi R Node SR> May 30 18:26:13 wks1 kernel: 852 supported_sleep_state R *Handler String [...] -netch- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: no psm interrupt; lock order reversal
Fri, Dec 06, 2002 at 23:07:36, netch (Valentin Nechayev) wrote about "no psm interrupt; lock order reversal": VN> 5.0-RC of 2002.12.05.12.00.00-UTC VN> Bigger problem that it can't obtain interrupts from PS/2 mouse, VN> hence mouse fails to work. systat shows no int 12 issued at all. ACPI disabling solved this. Sorry if it is common place now. VN> It is in both variant of IRQ12 setting in BIOS: to PCI and reserved for ISA. VN> In 4.7-release, all previous 4.*, and 5.0-current of 20020315, mouse works ok. -netch- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[OT] sendmail (Re: 5.0-RC2 informal PR: 90 sec sendmail delay)
Wed, Jan 01, 2003 at 21:39:33, tlambert2 (Terry Lambert) wrote about "Re: 5.0-RC2 informal PR: 90 sec sendmail delay": TL> It's an editorial complaint. I don't like the breaking the TL> program into seperate programs by function. IMO, DJB is wrong, TL> and this does nothing to enhance security. Can you please prove this conclusion, or at least show real arguments? Any MTA is big piece of little-structured code with unclear and mistransparent logic, full of errors, and when a piece of code has only those privileges which are survival for it, it provides additional barriers against exploiter. There are too many examples now where such restrictions (non-root execution, chroot,...) really kept against successful exploit. And DJB wasn't first, AFAIK; first was zmailer with its authors. (Please fix if I'm wrong.) TL> The result of doing TL> this in FreeBSD has been to greatly complicate rc scripts, with TL> the result that sendmail is much less of an unpluggable component TL> that can be replaced with something else, easily, and with little TL> system impact. Even in FreeBSD4 with its semi-monolithic /etc/rc, sendmail is easily startable from its own script. TL> I understand the "security" reasoning, based on having to compete TL> with qmail and other packages that claim this seperation magically TL> fixes all security issues. But it's just a propaganda move, and TL> it's not technically justified. It is technically justified. Do you have real arguments that any attack that can be performed with monolithic program run from root, is also successful with program with privilege separation? If you have such arguments, please show them. I see only counterexamples: privilege separation restricts possible attacks to a class which is rather more narrow than with monolithic design. TL> Similarly, the interior seperation, which is what resulted in the TL> DNS lookup that brought up the link in this current discussion TL> thread, fails via a timeout before the lookup is done, and so the TL> transfer fails. This has nothing common with privilege separation. Design of sendmail is too hard bound with concept of node constantly linked with Internet. To make it happy without full DNS accessible, you should perform some actions which are documented but their description hides in tons of ore. Standard FreeBSD configs hasn't got these options. You can send fix ;) TL> time that the timeout would fire, and the mail would never end up TL> getting sent (it would get aged into the queue as "can't lookup TL> destination host"). I fix it with: define(`confDIRECT_SUBMISSION_MODIFIERS',`CC u')dnl For now I has no such problem at my home machine. Yes, this solution isn't intuitive. TL> And one result is a FreeBSD where it's harder to pull sendmail out TL> and replace it (also a marketing win, from a sendmail perspective). TL> Personally, I use sendmail, so yanking it out is not high on my list TL> of things to do, but it's now harder to have base mail functionality TL> without parts of sendmail sticking around. I use sendmail, also. Possibly, due to old habit. But I'm waiting for moment when I can erase this crap from my hosts. -netch- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
no psm interrupt; lock order reversal
5.0-RC of 2002.12.05.12.00.00-UTC
Lock order reversal without panic:
lock order reversal
1st 0xc2e30708 vnode interlock (vnode interlock) @
/var/HEAD/src/sys/kern/vfs_subr.c:939
2nd 0xc033c3c0 vm page queue mutex (vm page queue mutex) @
/var/HEAD/src/sys/vm/vm_kern.c:424
Bigger problem that it can't obtain interrupts from PS/2 mouse,
hence mouse fails to work. systat shows no int 12 issued at all.
It is in both variant of IRQ12 setting in BIOS: to PCI and reserved for ISA.
In 4.7-release, all previous 4.*, and 5.0-current of 20020315, mouse works ok.
Dmesg and kernel config follows. Versions of files in lock order reversal
report:
* $FreeBSD: src/sys/kern/vfs_subr.c,v 1.420 2002/11/27 16:45:54 robert Exp $
* $FreeBSD: src/sys/vm/vm_kern.c,v 1.87 2002/08/25 00:22:31 alc Exp $
Motherboard: Leadtek WinFast 9100AX, on i815E
What another information should be provided to fix?
==={{{
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 5.0-RC-2002120512 #3: Fri Dec 6 20:40:09 EET 2002
[EMAIL PROTECTED]:/var/obj/var/HEAD/src/sys/nn15
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0474000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04740a8.
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 799435632 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (799.44-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x686 Stepping = 6
Features=0x383f9ff
real memory = 268369920 (255 MB)
avail memory = 255623168 (243 MB)
Initializing GEOMetry subsystem
Pentium Pro MTRR support enabled
VESA: v3.0, 8192k memory, flags:0x1, mode table:0xc03a9982 (122)
VESA: NVidia
npx0: on motherboard
npx0: INT 16 interface
acpi0: on motherboard
ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15
ACPI-0625: *** Info: GPE Block1 defined as GPE16 to GPE31
Using $PIR table, 10 entries at 0xc00fded0
acpi0: power button is handled as a fixed feature programming model.
Timecounter "ACPI-fast" frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
acpi_cpu0: on acpi0
acpi_tz0: on acpi0
acpi_button0: on acpi0
acpi_button1: on acpi0
pcib0: port 0x4000-0x40f7,0xcf8-0xcff on acpi0
pci0: on pcib0
agp0: mem 0xe400-0xe7ff at device
0.0 on pci0
pcib1: at device 1.0 on pci0
pci1: on pcib1
pci1: at device 0.0 (no driver attached)
pcib2: at device 30.0 on pci0
pci2: on pcib2
isab0: at device 31.0 on pci0
isa0: on isab0
atapci0: port 0xf000-0xf00f at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pcm0: port 0xdc00-0xdc3f,0xd800-0xd8ff irq 5 at device 31.5 on
pci0
speaker0 port 0x61 on acpi0
sio0 port 0x3f8-0x3ff irq 4 on acpi0
sio0: type 16550A
sio1 port 0x2f8-0x2ff irq 3 on acpi0
sio1: type 16550A
atkbdc0: port 0x64,0x60 irq 1 on acpi0
atkbd0: flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
orm0: at iomem 0xc-0xc7fff on isa0
pmtimer0 on isa0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
Timecounters tick every 10.000 msec
ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept,
logging unlimited
acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0%
ad0: DMA limited to UDMA33, non-ATA66 cable or device
ad0: 14664MB [29795/16/63] at ata0-master UDMA33
ad2: 39266MB [79780/16/63] at ata1-master UDMA100
acd0: CDROM at ata0-slave PIO4
MBREXT Slice 5 on ad0s2:
00 01 41 02 a5 fe 7f c9 3f 00 00 00 89 06 31 00 |..A.?.1.|
[0] f:00 typ:165 s(CHS):2/1/65 e(CHS):201/254/127 s:63 l:3212937
00 00 41 ca 05 fe 7f cd c8 06 31 00 04 fb 00 00 |..A...1.|
[1] f:00 typ:5 s(CHS):202/0/65 e(CHS):205/254/127 s:3213000 l:64260
MBREXT Slice 6 on ad0s2:
00 01 41 ca 83 fe 7f cd 3f 00 00 00 c5 fa 00 00 |..A.?...|
[0] f:00 typ:131 s(CHS):202/1/65 e(CHS):205/254/127 s:63 l:64197
00 00 41 ce 05 fe bf d0 cc 01 32 00 43 7d 3f 00 |..A...2.C}?.|
[1] f:00 typ:5 s(CHS):206/0/65 e(CHS):208/254/191 s:3277260 l:4160835
MBREXT Slice 7 on ad0s2:
00 01 41 ce 06 fe bf d0 3f 00 00 00 04 7d 3f 00 |..A.?}?.|
[0] f:00 typ:6 s(CHS):206/1/65 e(CHS):208/254/191 s:63 l:4160772
00 00 81 d1 05 fe ff ca 0f 7f 71 00 7a 48 3d 00 |..q.zH=.|
[1] f:00 typ:5 s(CHS):209/0/129 e(CHS):202/254/255 s:7438095 l:4016250
MBREXT Slice 8 on ad0s2:
00 01 81 d1 03 fe ff ca 3f 00 00 00 3b 48 3d 00 |?...;H=.|
[0] f:00 typ:3 s(CHS):209/1/129 e(CHS):202/254/255 s:63 l:4016187
00 00 c1 cb 05 fe ff ff 89 c7 ae 00 da 52 d2 00 |.R..|
[1] f:00 typ:5 s(CHS):203/0/193 e(CHS):255/254/255 s:11454345 l:13783770
MBREXT Slice 9 on ad0s2:
00 01 c1 cb a5 fe ff ff 3f 00 00 00 9b 52 d2 00 |?R..|
[0] f:00 typ:165
Re: cvsup weird problem
Fri, Dec 06, 2002 at 13:11:51, osa (Sergey A. Osokin) wrote about "Re: cvsup weird problem": SAO> Any other idea? :-) Remove src/contrib/gcc/INSTALL/ and sup checkouts directory simultaneously, this usually fixes such errors ;) > > > >> Delete src/contrib/gcc/INSTALL > > > >> Cannot delete "/usr/src/contrib/gcc/INSTALL": Directory not empty > > > >> > > > >> It's weird... >> Remove your src/contrib/gcc/INSTALL directory and try cvsup'ing again. >> The files in that directory were imported yesterday, and I think that >> David O'Brien didn't mean to import them at all: SAO> [skip] SAO> OK. I remove src/contrib/gcc/INSTALL, then resup: SAO> ... SAO> Updating collection src-all/cvs SAO> Checkout src/contrib/gcc/INSTALL/README SAO> Checkout src/contrib/gcc/INSTALL/binaries.html SAO> Checkout src/contrib/gcc/INSTALL/build.html SAO> Checkout src/contrib/gcc/INSTALL/configure.html SAO> Checkout src/contrib/gcc/INSTALL/download.html SAO> Checkout src/contrib/gcc/INSTALL/finalinstall.html SAO> Checkout src/contrib/gcc/INSTALL/gfdl.html SAO> Checkout src/contrib/gcc/INSTALL/index.html SAO> Checkout src/contrib/gcc/INSTALL/old.html SAO> Checkout src/contrib/gcc/INSTALL/specific.html SAO> Checkout src/contrib/gcc/INSTALL/test.html SAO> ... SAO> and then resup again: SAO> ... SAO> Establishing multiplexed-mode data connection SAO> Running SAO> Updating collection src-all/cvs SAO> Delete src/contrib/gcc/INSTALL SAO> Cannot delete "/usr/src/contrib/gcc/INSTALL": Directory not empty SAO> Shutting down connection to server -netch- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fd0c mount(8) Race
Sat, Jun 30, 2001 at 00:16:53, cristjc (Crist J. Clark) wrote about "fd0c mount(8) Race": > mount: /dev/fd0c: No such file or directory > That is, even though once I drop into single-user mode we see the > symlink for /dev/fd0c, it does not seem like it was there when 'mount > -a -t nonfs' is run in /etc/rc. I don't see it too. It appears if is created explicitly. Log follows (showing quite strange behavior): root@iv:~##ls -l /dev/fd0* crw-r- 1 root operator9, 0 Jul 1 15:01 /dev/fd0 root@iv:~##ls -l /dev/fd0c ls: /dev/fd0c: No such file or directory root@iv:~##mknod /dev/fd0c c 0 0 mknod: /dev/fd0c: File exists root@iv:~##ls -l /dev/fd0c lrw-rw-rw- 1 root wheel 4 Jul 1 19:31 /dev/fd0c -> fd0 root@iv:~##rm /dev/fd0c root@iv:~##rm /dev/fd0c rm: /dev/fd0c: No such file or directory root@iv:~##ls -l /dev/fd0c ls: /dev/fd0c: No such file or directory root@iv:~##ls -l /dev/fd0c ls: /dev/fd0c: No such file or directory root@iv:~##mknod /dev/fd0c c 0 0 root@iv:~##ls -l /dev/fd0c lrw-rw-rw- 1 root wheel 4 Jul 1 19:31 /dev/fd0c -> fd0 I'm surprised mainly that first mknod reported bogus failure. > reproduce the problem? Or is it well known (I can't find it in the > mail archive)? I think you can't - current devfs is too young. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: From -current to -stable?
Thu, Jun 21, 2001 at 15:02:37, TJ (T.J. Kniveton) wrote about "From -current to -stable?": > I followed the directions on the freebsd web site to grab the latest > -stable sources, but it looks like somehow I got the -current sources, > built and installed them (doh!). > > Everything is working ok, but this is my development laptop, and it > would probably be wiser to track -stable so that things will still work. > I have grabbed the RELENG_4 source, but it is dying at unctrl.h. Is > there any way to go backward from an installed current build, to stable? 1. Do binary install. 2. Make world with includes from RELENG_4. I successfully did it with /usr/include copied from another 4-stable host. Maxim Sobolev recommended to do `make includes' before `make buildworld'. A rumour was that it is already fixed (building doesn't depend on host includes) but... /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with md5 -p
Sun, Jun 24, 2001 at 13:16:07, stephen (Stephen Montgomery-Smith) wrote about "Re:
Problems with md5 -p":
> OK, I'm going to make this into a PR so that it gets fixed soon. (The
> problem in stable appeared between May 19 and June 16.)
Yes, it appeared with commits:
ru 2001/05/22 03:33:44 PDT
Modified files:
sbin/md5 Makefile md5.c
Removed files:
sbin/md5 global.h
Log:
Fix argument processing.
Make this compile with WARNS=2.
PR: bin/27524
MFC after:3 days
Revision ChangesPath
1.5 +3 -1 src/sbin/md5/Makefile
1.22 +46 -52src/sbin/md5/md5.c
ru 2001/05/26 05:08:35 PDT
Modified files:(Branch: RELENG_4)
sbin/md5 md5.c
Removed files: (Branch: RELENG_4)
sbin/md5 global.h
Log:
MFC: fix argument processing.
Revision ChangesPath
1.20.2.2 +46 -52src/sbin/md5/md5.c
Before them the case when MDFilter(0) should be called, checked separately
(argc==1). After them it is not checked, "fix argument processing"
is somehow wrong. IMO these commits should be reverted.
> Valentin Nechayev wrote:
> >
> > Sun, Jun 24, 2001 at 09:25:22, stephen (Stephen Montgomery-Smith) wrote about
>"Problems with md5 -p":
> >
> > I reproduce it stably on my -current. The second checksum is constant
> > and it is MD5 checksum of an empty stream:
> >
> > root@iv:/usr/HEAD/src/sbin/md5##md5 > d41d8cd98f00b204e9800998ecf8427e
> >
> > A fix:
> >
> > --- md5.c.orig Mon Jun 4 00:38:02 2001
> > +++ md5.c Sun Jun 24 19:37:13 2001
> > @@ -65,7 +65,7 @@
> > switch (ch) {
> > case 'p':
> > MDFilter(1);
> > - break;
> > + exit(0);
> > case 'q':
> > qflag = 1;
> > break;
> >
> > This avoids determination of other options, but this does not conflict
> > directly with man page.
> >
> > Moreover such exit(0) should be applied not only with -p, but also with
> > -x, -t and -s: all these options should not gather any input files.
> > Patch is trivial.
> >
> > > Suppose I have a file xxx. If I type
> > >
> > > md5 -p < xxx
> > >
> > > it should return the contents of the file followed by its md5 number:
> > >
> > > Some junk in the file
> > >
> > > 334911f8bcde69fe8edac561197e876f
> > >
> > > But now I get two numbers:
> > >
> > > Some junk in the file
> > >
> > > 334911f8bcde69fe8edac561197e876f
> > > d41d8cd98f00b204e9800998ecf8427e
> > >
> > > This is using FreeBSD stable of June 16. (Maybe this has been fixed
> >
> > > more recently - please tell me of it has. It is a bit tricky for me to
> > > update sources because I use CTM which has been out recently - probably
> > > for just this very reason. But if I know the problem has been fixed
> > > then I will go through the effort of using cvsup.)
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: su broken?
Sun, Jun 24, 2001 at 19:21:20, rb (Bob Bishop) wrote about "su broken?": > su appears to be asking for a password when invoked by root, eg: > > # su bin -c "pwd" > Password: root@iv:~##su bin -c pwd This account is currently not available. root@iv:~##su -m bin -c pwd /root > Broken, surely? root@iv:~##ident /usr/bin/su /usr/bin/su: $FreeBSD: src/usr.bin/su/su.c,v 1.39 2001/05/26 09:52:36 markm Exp $ And what is of yours? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with md5 -p
Sun, Jun 24, 2001 at 09:25:22, stephen (Stephen Montgomery-Smith) wrote about "Problems with md5 -p": I reproduce it stably on my -current. The second checksum is constant and it is MD5 checksum of an empty stream: root@iv:/usr/HEAD/src/sbin/md5##md5 Suppose I have a file xxx. If I type > > md5 -p < xxx > > it should return the contents of the file followed by its md5 number: > > Some junk in the file > > 334911f8bcde69fe8edac561197e876f > > But now I get two numbers: > > Some junk in the file > > 334911f8bcde69fe8edac561197e876f > d41d8cd98f00b204e9800998ecf8427e > > This is using FreeBSD stable of June 16. (Maybe this has been fixed > more recently - please tell me of it has. It is a bit tricky for me to > update sources because I use CTM which has been out recently - probably > for just this very reason. But if I know the problem has been fixed > then I will go through the effort of using cvsup.) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ptys & devfs
I. A session under screen, or sshd, or any another: netch@iv:~>tty /dev/ttyp2 netch@iv:~>ls -l /dev/tty /dev/ttyp2 crw--w 1 netch tty5, 2 Jun 24 13:09 /dev/tty crw--w 1 netch tty5, 2 Jun 24 13:09 /dev/ttyp2 root@iv:~##ls -l /dev/ttyp* crw--w 1 netch tty5, 2 Jun 24 13:09 /dev/ttyp2 crw--w 1 netch tty5, 3 Jun 24 13:09 /dev/ttyp3 Then try unlink /dev/ttyp2: root@iv:~##rm /dev/ttyp2 root@iv:~##ls -l /dev/ttyp* crw--w 1 netch tty5, 3 Jun 24 13:10 /dev/ttyp3 And then from first session: netch@iv:~>tty not a tty netch@iv:~>ls -l /dev/tty /dev/ttyp* crw--w 1 netch tty5, 2 Jun 24 13:10 /dev/tty crw--w 1 netch tty5, 3 Jun 24 13:10 /dev/ttyp3 Why it allows to unlink pty which in use? (The same with master pty: kernel allows to unlink used master pty.) When exit from the session and enter again, screen complaints: "chown tty: No such file or directory". This shit keeps itself even if terminate screen and start it again: "chown tty: No such file or directory" "Sorry, could not find a PTY." & exit `mknod /dev/ttyp2 c 0 0' fixes it. But this logic is rather opaque: before screen's request, /dev/ttyp2 did not exist, but created on open(); but why it cannot be opened again now? And ptys which are already not used keeps themselves in /dev listing. II. fstat says strange `(11)' on all ptys, e.g.: netchfstat 126930 - - ?(11)- netchfstat 126931* pipe c870dc00 <-> c870df20 0 rw netchfstat 126932 - - ?(11)- netchfstat 126933 - - ?(11)- netchfstat 126934 - - ?(11)- But this fstat was run in terminal which: netch@iv:~>tty /dev/ttyr0 netch@iv:~>ls -l /dev/ttyr0 crw--w 1 netch tty5, 64 Jun 24 13:16 /dev/ttyr0 No experiments described above were performed upon /dev/ttyr0, it is kept virgin, with most of another ptys at this run. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ps 'D' state - ?
Sat, Jun 16, 2001 at 23:21:33, Tor.Egge ([EMAIL PROTECTED]) wrote about "Re: ps 'D' state - ?": > > Are `select' and `nanosleep' disk uninterruptable waits? ;| > No. The ps command gave wrong output. > flag = k->ki_p->ki_flag; > - sflag = k->ki_p->ki_flag; > + sflag = k->ki_p->ki_sflag; OK, it seems fixed. Let's commit it. ;) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ps 'D' state - ?
root@iv:~##ps 4986 PID TT STAT TIME COMMAND 4986 ?? DWs0:01.01 /usr/sbin/sshd root@iv:~##ps 4986 -l UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 4986 1 52 102 0 2292 430 select DWs ??0:01.01 /usr/sbin/ss netch@iv:~>ps 218 -l UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 218 1 0 8 0 1120 176 nanslp DWs ??0:02.31 diskcheckd: Are `select' and `nanosleep' disk uninterruptable waits? ;| /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Terminal line discipline is broken [sorta]
Thu, Jun 07, 2001 at 12:04:10, bde (Bruce Evans) wrote about "Re: Terminal line discipline is broken [sorta]": > This may be a bug in tcsh. Do you really think that shell should not modify signal handling policy which he obtained as legacy from login? And application which resets them to appropriate position is buggy? > > It is very strange, but control keys [^C,^Z etc] no longer work (nop) > > in the /bin/sh and bash2 after today's build/installworld. I see this > > misbehaviour on two machines. > PAM now blocks keyboard signals when reading the password, and usually > forgets to unblock them. I use the workaround of backing out the broken > code (rev.1.4 of /usr/src/contrib/libpam/libpam_misc/misc_conv.c). > > Even more strange that /bin/tcsh doesn't > > have this problem. My ktracing of bash (2.04) shows that it isn't really set procmask to own values, but uses legacy value. Maybe I'm wrong, but this seems that sh & bash are buggy, not tcsh. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: free: multiple frees
-current, cvsup: date=2001.06.03.00.00.00 Normally worked, but after Ctrl-Alt-Del: IdlePTD 4038656 initial pcb at 32f940 panicstr: from debugger panic messages: --- panic: free: multiple frees panic: from debugger Uptime: 25m49s (kgdb) bt #0 0xc0199a36 in dumpsys () #1 0xc0199823 in boot () #2 0xc0199c3d in panic () #3 0xc01201d5 in db_panic () #4 0xc0120175 in db_command () #5 0xc012023a in db_command_loop () #6 0xc0122403 in db_trap () #7 0xc02881aa in kdb_trap () #8 0xc0295450 in trap () #9 0xc0288418 in Debugger () #10 0xc0199c34 in panic () #11 0xc0193089 in free () #12 0xc01d0807 in cache_zap () #13 0xc01d0d50 in cache_purgevfs () #14 0xc01d9c4f in dounmount () #15 0xc01d839e in vfs_unmountall () #16 0xc019978f in boot () #17 0xc0199144 in reboot () #18 0xc0296061 in syscall () #19 0xc0288c8d in syscall_with_err_pushed () #20 0x80486ca in ?? () #21 0x80484a3 in ?? () #22 0x8048125 in ?? () (no debug symbols yet, sorry) Startup dmesg: Copyright (c) 1992-2001 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 5.0-CURRENT #0: Mon Jun 4 09:11:46 EEST 2001 [EMAIL PROTECTED]:/usr/obj/usr/HEAD/src/sys/nn12 Setting fdc 0 at to isa (string) Setting fdc 0 port to 1008 (int) Setting fdc 0 irq to 6 (int) Setting fdc 0 drq to 2 (int) Setting fd 0 at to fdc0 (string) Setting fd 0 drive to 0 (int) Setting fd 1 at to fdc0 (string) Setting fd 1 drive to 1 (int) Setting ata 0 at to isa (string) Setting ata 0 port to 496 (int) Setting ata 0 irq to 14 (int) Setting ata 1 at to isa (string) Setting ata 1 port to 368 (int) Setting ata 1 irq to 15 (int) Setting adv 0 at to isa (string) Setting bt 0 at to isa (string) Setting aha 0 at to isa (string) Setting aic 0 at to isa (string) Setting atkbdc 0 at to isa (string) Setting atkbdc 0 port to 96 (int) Setting atkbd 0 at to atkbdc (string) Setting atkbd 0 irq to 1 (int) Setting atkbd 0 flags to 1 (int) Setting psm 0 at to atkbdc (string) Setting psm 0 irq to 12 (int) Setting vga 0 at to isa (string) Setting sc 0 at to isa (string) Setting sc 0 flags to 256 (int) Setting vt 0 at to isa (string) Setting npx 0 at to nexus (string) Setting npx 0 port to 240 (int) Setting npx 0 irq to 13 (int) Setting apm 0 at to nexus (string) Setting apm 0 disabled to 1 (int) Setting apm 0 flags to 32 (int) Setting pmtimer 0 at to isa (string) Setting pcic 0 at to isa (string) Setting pcic 0 port to 992 (int) Setting pcic 0 maddr to 851968 (int) Setting pcic 1 at to isa (string) Setting pcic 1 irq to 11 (int) Setting pcic 1 port to 994 (int) Setting pcic 1 maddr to 868352 (int) Setting pcic 1 disabled to 1 (int) Setting sio 0 at to isa (string) Setting sio 0 port to 1016 (int) Setting sio 0 flags to 16 (int) Setting sio 0 irq to 4 (int) Setting sio 1 at to isa (string) Setting sio 1 port to 760 (int) Setting sio 1 irq to 3 (int) Setting sio 2 at to isa (string) Setting sio 2 disabled to 1 (int) Setting sio 2 port to 1000 (int) Setting sio 2 irq to 5 (int) Setting sio 3 at to isa (string) Setting sio 3 disabled to 1 (int) Setting sio 3 port to 744 (int) Setting sio 3 irq to 9 (int) Setting ppc 0 at to isa (string) Setting ppc 0 irq to 7 (int) Setting ed 0 at to isa (string) Setting ed 0 port to 640 (int) Setting ed 0 irq to 10 (int) Setting ed 0 maddr to 884736 (int) Setting cs 0 at to isa (string) Setting cs 0 port to 768 (int) Setting sn 0 at to isa (string) Setting sn 0 port to 768 (int) Setting sn 0 irq to 10 (int) Setting ie 0 at to isa (string) Setting ie 0 port to 768 (int) Setting ie 0 irq to 10 (int) Setting ie 0 maddr to 851968 (int) Setting fe 0 at to isa (string) Setting fe 0 port to 768 (int) Setting le 0 at to isa (string) Setting le 0 port to 768 (int) Setting le 0 irq to 5 (int) Setting le 0 maddr to 851968 (int) Setting lnc 0 at to isa (string) Setting lnc 0 port to 640 (int) Setting lnc 0 irq to 10 (int) Setting lnc 0 drq to 0 (int) Setting adv 0 at to isa (string) Setting aha 0 at to isa (string) Setting aic 0 at to isa (string) Setting apm 0 at to nexus (string) Setting apm 0 disabled to 1 (int) Setting apm 0 flags to 32 (int) Setting ata 0 at to isa (string) Setting ata 0 irq to 14 (int) Setting ata 0 port to 496 (int) Setting ata 1 at to isa (string) Setting ata 1 irq to 15 (int) Setting ata 1 port to 368 (int) Setting atkbd 0 at to atkbdc (string) Setting atkbd 0 flags to 1 (int) Setting atkbd 0 irq to 1 (int) Setting atkbdc 0 at to isa (string) Setting atkbdc 0 port to 96 (int) Setting bt 0 at to isa (string) Setting cs 0 at to isa (string) Setting cs 0 port to 768 (int) Setting ed 0 at to isa (string) Setting ed 0 irq to 10 (int) Setting ed 0 maddr to 884736 (int) Setting ed 0 port to 640 (int) Setting fd 0 at to fdc0 (string) Setting fd 0 drive to 0 (int) Setting fd 1 at to fdc0 (string) Setting fd 1 drive to 1 (int) Setting fdc 0 at to isa (string) Setting fdc 0 drq to 2 (int) Setting fdc 0 irq to 6 (int) Setting fdc 0 port
Re: Boot time memory issue
Sat, May 26, 2001 at 22:03:34, barry (Barry Lustig) wrote about "Re: Boot time memory
issue":
> > > SMAP type=01 base= 0010 len= 13ef
[...]
> Did that and got the same error. I put a printf just before the
> pa_indx++ in machdep.c and watched it increment by 2's all the way up to
> 100.
>
> Any other ideas?
This code in machdep.c performs easy memory test for each page and adds
it to previous chunk or creates new one. The idea AFAIU is to test
declared memory regions for real ones. If you have >100 really different
regions in declared two memory regions, something bad happened with
your hardware: memory modules are broken, or chipset incorrectly detects
them, or yet another problem...
You can test its logic by adding following patch or similar one:
--- machdep.c.orig Sun May 27 11:12:19 2001
+++ machdep.c Sun May 27 11:13:57 2001
@@ -1785,10 +1785,12 @@
printf("Too many holes in the physical address
space, giving up\n");
pa_indx--;
break;
}
phys_avail[pa_indx++] = pa; /* start */
+ printf( "getmemsize: new chunk at %08lx\n",
+ (unsigned long) pa );
phys_avail[pa_indx] = pa + PAGE_SIZE; /* end */
}
physmem++;
}
}
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: downgrade
Wed, May 23, 2001 at 15:43:50, nk (Norbert Koch) wrote about "downgrade": > Is it possible to downgrade a machine from -current to -stable? A ~month ago I downgraded my home system from -current to -stable (RELENG_4) via buildworld+installworld. But to do it successfully I had to replace /usr/include with the same from working 4.2-STABLE system, because of too many fallings of buildworld with -current headers. Current (not -current;)) but "contemporary") world building procedure does not exclude headers from /usr/include out of compiler view. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Date for a working -current?
Wed, May 23, 2001 at 21:26:37, jkoshy (Joseph Koshy) wrote about "Date for a working -current?": > I'm in the processing of bring a 5-current system of Oct 2000 vintage > more upto-date. > The kernel built around May 23rd 2001, has been quite unstable, with > numerous warning on lock order reversals, and alas, frequent panics, mostly > on account of processes sleeping while holding mutexes. The simplest way for seeing almost-guaranteed working -current is 1) read -current of 1-2 days ago, 2) find moment where there are no "Who put boot onto Red Button???" cries, 3) set up date= in supfile for good moment, but at least 24 hours ago, 4) cvsup & make world. But with this approach you only can deal with longstanding issues and you are excluded from quick discovering-and-fixing. Let's suppose this is adoptable for you and others. > Its been a while since -current was like this :). My priority is to build > a reasonably upto-date userland. So, my question is: what is a known good > date that I can upgrade the machine to? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Boot time memory issue
Sun, May 20, 2001 at 19:53:29, barry (Barry Lustig) wrote about "Boot time memory issue": Do verbose boot (`boot -v') with large SC_HISTORY_SIZE (1000 at least, 2000 at most), and after boot check for "SMAP ..." lines at the very beginning of the kernel boot log at /dev/console. (They are not written to log viewable with dmesg.) Another way is to use serial console. With this SMAP lines one can say more concrete diagnosis. > I was curious whether the memory limitation on the Sony VAIO Z505 > machines was an actual hardware limitation or a marketing issue. I just > tried adding a 256MB module to my machine. The BIOS seemed to mostly > recognize it. > It did see 320MB of RAM, but had problems when testing all of it. > Current (from > a couple of weeks ago) boots, but gives me: > Too many holes in the physical address space, giving up > > and comes up showing 64MB of RAM. Is this something that can be worked > around, or have I run up against an actual hardware limit on the > machine? /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: random woes ("no RSA support in libssl and libcrypto")
Tue, Mar 27, 2001 at 11:33:11, mark (Mark Murray) wrote about "Re: random woes ("no
RSA support in libssl and libcrypto")":
> > Well, but it says about `options RANDOMDEV'. Later, `device random' was
> > invented instead of it. A few days ago I installed -CURRENT
> > (date=2001.03.25.12.00.00) with removing all previous content of /usr/lib
> > (which contained legacy since 3.1-RELEASE) and /usr/sbin/sshd began to refuse
> > supporting protocol 1 with identical message
> > (`no RSA support in libssl and libcrypto. See ssl(8)'). Also,
> > kernel was build with `device random', and
> >
> > netch@iv:/usr/HEAD/src/sys/i386/conf>egrep '(RSA|USA)' /etc/make.conf
> > # If you're resident in the USA, this will help various ports to determine
> > USA_RESIDENT= NO
> > WITH_RSA=YES
> You missed (and deleted) the bit where it tells you to rerun MAKEDEV
> to rebuild your devices.
No, /dev/urandom was correct, 'MAKEDEV all' was run properly.
The only change was to remove old libraries, which are not installed
via installworld in modern -CURRENT, from /usr/lib.
> > And, my questions are
> > 1) What can happen to refuse RSA support in libcrypto, with environment
> > described above?
> An incorrect /dev/urandom
No.
> > 3) Can anybody provide more descriptive message when random device
> > works improperly?
> Yes. I'm working on making the random device itself moan at you.
Thank you for polite reply.;) But, the problem is not solved in this way.
That's why I asked some description how to diagnose these problems.
Instead of its I received random moans. Ok, thanks.
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: random woes ("no RSA support in libssl and libcrypto")
Mon, Mar 19, 2001 at 16:02:08, mark (Mark Murray) wrote about "Re: random woes ("no
RSA support in libssl and libcrypto")":
> > ssh: no RSA support in libssl and libcrypto. See ssl(8)
[...]
> > It seems the compatibility with the previous minor of urandom has
> > been silently removed (I assume this happened with the last
> > update/cleanup of the random device). It took me two hours to figure
> > it out.
>
> See src/UPDATING 2624
Well, but it says about `options RANDOMDEV'. Later, `device random' was
invented instead of it. A few days ago I installed -CURRENT
(date=2001.03.25.12.00.00) with removing all previous content of /usr/lib
(which contained legacy since 3.1-RELEASE) and /usr/sbin/sshd began to refuse
supporting protocol 1 with identical message
(`no RSA support in libssl and libcrypto. See ssl(8)'). Also,
kernel was build with `device random', and
netch@iv:/usr/HEAD/src/sys/i386/conf>egrep '(RSA|USA)' /etc/make.conf
# If you're resident in the USA, this will help various ports to determine
USA_RESIDENT= NO
WITH_RSA=YES
And, my questions are
1) What can happen to refuse RSA support in libcrypto, with environment
described above?
2) How can one diagnose reason of such problems without abusing studying
of libcrypto internals?
3) Can anybody provide more descriptive message when random device
works improperly?
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /etc/exports: 192.168.5 = 192.168.0.5
> > /var -alldirs -maproot=root: -network 192.168.5 -mask 255.255.255.0 > > showmount -e showed 192.168.5 was being interpreted as 192.168.0.5 > This is the correct interpretation. > > Changing -network to 192.168.5.0 fixed it, naturally, but the 192.168.5 > > used to work. > It was broken, then. :-) 192.168.5 should be interpreted as 192.168.0.5 in host address context, but as 192.168.5.0 in network address context. (Such network address context is well seen in sentences such as "10/8", "192.168/16".) netch@iv:~/tmp>netstat -rn | grep 192 192/8 127.0.0.1 UGSc00 lo0 In case in question, when -network prefix is occured, parsing should be performed with network address context, not host address context. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Interesting backtrace...
Sun, Mar 18, 2001 at 16:41:03, des (Dag-Erling Smorgrav) wrote about "Interesting backtrace...": > I finally caught a backtrace from one of those recurring stack smash > panics. I've been getting a few of these every day for a couple of > weeks now but never caught a dump; I caught this one by typing 'panic' > immediately instead of trying to get a trace at the ddb prompt first. [...] > #11 0x037f in ?? () > #12 0xc023c8bb in vm_fault (map=0xd0768a00, vaddr=138502144, > fault_type=2 '\002', fault_flags=8) at ../../vm/vm_page.h:493 I seen a bunch of identical panics on my home system (5.0-current of ~2001.02.27.22.10.00 UTC). I did not reported them yet because of lack of understanding what's happen because pmap_zero_page() call is occured in vm_fault() without this call in source code ;| > Looks to me like there was a page fault, and the stack got corrupted > while handling that fault (possibly somewhere in pmap_zero_page(), > called from vm_page_zero_fill() which is inlined in vm_fault()). > (BTW, this is a K6-2, which as far as I can tell is a 586-class CPU) The same, K6-2: CPU: AMD-K6(tm) 3D processor (298.96-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping = 12 Features=0x8021bf AMD Features=0x8800 /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel logging under heavy load
A simple but intensive fork bomb were started on 5.0-current UP machine.
After it, /var/log/messages contains:
Mar 3 19:16:46 iv /boot/kernel/kernel: roc: table is full
Mar 3 19:16:46 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:46 iv last message repeated 42 times
Mar 3 19:16:46 iv /boot/kernel/kernel: proc: table <3>proc: table is full
Mar 3 19:16:46 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:47 iv last message repeated 41 times
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is fs full
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:47 iv last message repeated 42 times
Mar 3 19:16:47 iv /boot/kernel/kernel: proc:ll
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:47 iv last message repeated 43 times
Mar 3 19:16:47 iv /boot/kernel/kernel: table is full
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:47 iv last message repeated 42 times
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is futable is full
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:47 iv last message repeated 42 times
Mar 3 19:16:47 iv /boot/kernel/kernel: l
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:47 iv last message repeated 43 times
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: l
Mar 3 19:16:47 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:16:50 iv last message repeated 10212 times
Mar 3 19:17:16 iv /boot/kernel/kernel: roc: table is full
Mar 3 19:17:16 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 42 times
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table roc: table is full
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 42 times
Mar 3 19:17:17 iv /boot/kernel/kernel: ull
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 43 times
Mar 3 19:17:17 iv /boot/kernel/kernel: procull
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 43 times
Mar 3 19:17:17 iv /boot/kernel/kernel: table is full
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 42 times
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is f table is full
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 42 times
Mar 3 19:17:17 iv /boot/kernel/kernel: ll
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 43 times
Mar 3 19:17:17 iv /boot/kernel/kernel: proc:ll
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 43 times
Mar 3 19:17:17 iv /boot/kernel/kernel: table is full
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 42 times
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is futable is full
Mar 3 19:17:17 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:17 iv last message repeated 42 times
Mar 3 19:17:17 iv /boot/kernel/kernel: l
Mar 3 19:17:18 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:18 iv last message repeated 43 times
Mar 3 19:17:18 iv /boot/kernel/kernel: proc: l
Mar 3 19:17:18 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:18 iv last message repeated 3524 times
Mar 3 19:17:46 iv /boot/kernel/kernel: roc: table is full
Mar 3 19:17:46 iv /boot/kernel/kernel: proc: table is full
Mar 3 19:17:47 iv last message repeated 3559 times
The message is generated with command
kern_fork.c:246:tablefull("proc");
The system in question is UP, 5.0-current of 2001-02-27
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
random fallback init
The problem that when random device was not seeded, boot simply hangs (on
ldconfig! why?) Ugly init(8) gives no chance to stop booting and fall to
reboot or single mode again via ctrl-alt-del or another key combination;
sleeping on "rndblk" channel in ldconfig is not interruptible; only DDB or
Reset button save, with respective results as fsck need;(
Patch below is not simply patch (I suppose Mark Murray is good programmer,
and I am too lame to learn him how to program), but quick (and dirty?)
realization of requirement that random device must work even when it was not
seeded externally, and it works in patched variant at my system:
==={{{ screenshot part
Starting final network daemons:.
setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/li
b
random_read: no seed yet, provide fallback
setting a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/a
out
starting standard daemons: cron sendmail sshd.
===}}}
Of course, it should be combined with patch of /etc/rc (see letter to -current:
`From: Doug Barton <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>').
diff -rNu src.orig/sys/dev/random/randomdev.c src/sys/dev/random/randomdev.c
--- src.orig/sys/dev/random/randomdev.c Sat Oct 14 13:59:54 2000
+++ src/sys/dev/random/randomdev.c Mon Oct 16 11:07:29 2000
@@ -113,7 +113,11 @@
error = EWOULDBLOCK;
}
else {
- if (random_state.seeded) {
+ if (!random_state.seeded) {
+ printf("random_read: no seed yet, provide fallback\n");
+ reseed(FAST);
+ }
+ if (1) {/* if(random_state.seeded) was here */
c = min(uio->uio_resid, PAGE_SIZE);
random_buf = (void *)malloc(c, M_TEMP, M_WAITOK);
while (uio->uio_resid > 0 && error == 0) {
@@ -122,8 +126,6 @@
}
free(random_buf, M_TEMP);
}
- else
- error = tsleep(&random_state, 0, "rndblk", 0);
}
return error;
}
diff -rNu src.orig/sys/dev/random/yarrow.c src/sys/dev/random/yarrow.c
--- src.orig/sys/dev/random/yarrow.cSat Oct 14 13:59:54 2000
+++ src/sys/dev/random/yarrow.c Mon Oct 16 11:02:17 2000
@@ -268,7 +268,7 @@
#endif
}
-static void
+void
reseed(int fastslow)
{
/* Interrupt-context stack is a limited resource; make large
@@ -355,9 +355,6 @@
/* 7. Dump to seed file */
/* XXX Not done here yet */
- /* Release the reseed mutex */
- mtx_exit(&random_reseed_mtx, MTX_DEF);
-
#ifdef DEBUG
printf("Reseed finish\n");
#endif
@@ -367,6 +364,9 @@
selwakeup(&random_state.rsel);
wakeup(&random_state);
}
+
+ /* Release the reseed mutex */
+ mtx_exit(&random_reseed_mtx, MTX_DEF);
}
diff -rNu src.orig/sys/dev/random/yarrow.h src/sys/dev/random/yarrow.h
--- src.orig/sys/dev/random/yarrow.hSat Oct 14 13:59:54 2000
+++ src/sys/dev/random/yarrow.h Mon Oct 16 11:02:32 2000
@@ -46,6 +46,7 @@
void random_init_harvester(void (*)(struct timespec *, void *, u_int, u_int, u_int,
enum esource), u_int (*)(void *, u_int));
void random_deinit_harvester(void);
void random_set_wakeup_exit(void *);
+void reseed(int);
u_int read_random_real(void *, u_int);
void write_random(void *, u_int);
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: (1) hanging up on ldconfig; (2) entropy file read failed
Sun, Oct 15, 2000 at 20:52:59, netch wrote about "(1) hanging up on ldconfig; (2) entropy file read failed": This is also entropy file and random device problem. ldconfig which hangs: pid=107, flag=004006, stat=3, wchan=c0336f80, wmesg=rndblk - waits for random data (?) This handing appeared with new random driver and setting entropy_file="NO" Why driver hangs when no seed was set? > System is: FreeBSD 5.0(13)-CURRENT-20001014 > > Three times, it hung up during boot after message: > setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/li > b > > trace from DDB said: > > [scgets and neighbours stuff] > atbkd_isa_intr() > ithd_loop() at ithd_loop+0x8a > fork_trampoline() at fork_trampoline+0x1b > > After that, I booted it to single mode, and after "ldconfig" (without > params) the hanging happened again. At 4th boot, it booted normally, > hence I came too late with idea to read kernel debugging section of handbook;| > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > About entropy file. At my home system, /var is not at / (it is symlink to > /usr/var). /etc/rc reads entropy file before mounting all filesystems, > and it failed and fell back to cat'ing /etc/* ;| > Should it be better to read entropy file after mounting all filesystems? > Imho it is incorrect to place it on root FS. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(1) hanging up on ldconfig; (2) entropy file read failed
System is: FreeBSD 5.0(13)-CURRENT-20001014 Three times, it hung up during boot after message: setting ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/li b trace from DDB said: [scgets and neighbours stuff] atbkd_isa_intr() ithd_loop() at ithd_loop+0x8a fork_trampoline() at fork_trampoline+0x1b After that, I booted it to single mode, and after "ldconfig" (without params) the hanging happened again. At 4th boot, it booted normally, hence I came too late with idea to read kernel debugging section of handbook;| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - About entropy file. At my home system, /var is not at / (it is symlink to /usr/var). /etc/rc reads entropy file before mounting all filesystems, and it failed and fell back to cat'ing /etc/* ;| Should it be better to read entropy file after mounting all filesystems? Imho it is incorrect to place it on root FS. /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
At Fri, 6 Oct 2000 22:00:23 + (UTC), jhb wrote: JB> The problem was that the interrupt threads for the clk interrupt introduced JB> enough latency that occasionally (mostly during a heavy load of interrupts) JB> tc_windup() wasn't called soon enough to update the timecounter. Making On my system _each_ boot causes hundreds of these messages. And as described, long offsets without updating are caused by some code in drivers, i.e. DELAY(100) in isa/fd.c. Is it nesessary to call tc_windup() between iterations in isa_configure? ;| JB> clock interrupts not be threaded fixes this problem. Oh, well, I understand now that scheduling is nesessary to be run early because interrupts are implemented as kernel threads even when kernel is in phase of hardware detection.;( /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
microuptime() went backwards: possible diagnosis
Following is partial dmesg output from 5.0(13)-CURRENT-20001002 kernel
with advanced debugging prints:
==={{{
mi_startup(): call subsystem 0x880(142606336), microuptime is 1.4027506
mi_startup(): call subsystem 0x880(142606336), microuptime is 1.4027897
mi_startup(): call subsystem 0xa00(167772160), microuptime is 1.4028290
mi_startup(): call subsystem 0xa80(176160768), microuptime is 1.4028701
mi_switch(): microuptime() went backwards (1.4029032 -> 0.734106)
mi_switch(): microuptime() went backwards (1.4029032 -> 0.734590)
mi_switch(): microuptime() went backwards (1.4029032 -> 0.735077)
mi_switch(): microuptime() went backwards (1.4029032 -> 0.73)
[...]
mi_switch(): microuptime() went backwards (1.4029032 -> 1.053263)
mi_switch(): microuptime() went backwards (1.4029032 -> 1.053756)
mi_startup(): call subsystem 0xd00(218103808), microuptime is 1.054550
proc0_post(): switchtime initialized to 1.54864
mi_startup(): call subsystem 0xe00(234881024), microuptime is 1.055501
mi_startup(): call subsystem 0xe40(239075328), microuptime is 1.056012
===}}}
mi_switch() uses static variable 'switchtime' which keeps microuptime
data when previous switching occured. For non-MP systems, proc0_post()
sets it up. But first mi_switch() call occures when SI_SUB_INT_CONFIG_HOOKS
(or SI_SUB_KICK_SCHEDULER?) subsystem called - why? IMHO it is too early
for mi_switch(), it should be enabled on SI_SUB_RUN_SCHEDULER.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This was first question. Another one is strange value returned by
microuptime() (3-5 millions of microseconds). This value becomes strange
on my system during third SI_SUB_CONFIGURE instance, which is configure()
in i386/i386/autoconf.c:
[...]
isa_probe_children: before probing non-PNP device: microuptime=0.349777, x=0
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd.c: fd_probe(): before set_motor(): microuptime=0.291463, x=0
fdc0: FIFO enabled, 8 bytes threshold
fd.c: fd_probe(): before NE7CMD_SENSED(): microuptime=1.292409, x=0
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
isa_probe_children: after probing non-PNP device: microuptime=1.1653283, x=0
isa_probe_children: before probing non-PNP device: microuptime=1.1604514, x=7
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
isa_probe_children: after probing non-PNP device: microuptime=1.3138749, x=7
[...]
it isn't possible to normalize value during this subsystem startup, is it?
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: load average is 1 when no processes active; etc.
Hello Bruce Evans!
Mon, Sep 11, 2000 at 03:09:02, bde wrote about "Re: load average is 1 when no
processes active; etc.":
> > `top -I' output:
> >
> > ==={
> > last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26
>
> This is because the idle process is always running (see "ps lax" outout).
> Perhaps the bug is that top doesn't show the idle process or other interesting
> kernel processes like the new interrupt processes.
top does nothing to determine LA except getting sysctl "vm.loadavg", isn't it?
("uptime" and "w" says the same avenrun/LA values.)
Imho, idle process should not be determined as always running,
and idle process state should be fixed.
> > IP Filter: v3.4.9 initialized. Default = pass all, Logging = enabled
> > microuptime() went backwards (1.3891137 -> 0.596214)
> > microuptime() went backwards (1.3891137 -> 0.596655)
> > ...
>
> I get these at boot time on one machine but not on another very similar
> machine, and often after messing around with ddb. TSC timecounter in
> all cases. I think they are not a serious problem or related to old
> timecounter bugs, but they may be related to old bugs setting `switchtime'.
What information of my hardware should be reported additionally?
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: microuptime() went backwards
Hello John Baldwin! >> microuptime() went backwards (1.7682417 -> 1.997434) >> >> I recall reading in -current earlier this week that someone was >> looking for victims getting this. What further information can I provide? JB> This is a SMPng issue on UP machines. I have obtained the same on non-SMP machine. (See my parallel letter.) /netch To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
load average is 1 when no processes active; etc.
System in question is:
root@nn:~##uname -mrs
FreeBSD 5.0-CURRENT i386
root@nn:~##grep FreeBSD_version /usr/include/sys/param.h
#undef __FreeBSD_version
#define __FreeBSD_version 500012/* Master, propagated to newvers */
root@nn:~##
cvsup was Sep 8, approximately at 18:00 GMT.
`top -I' output:
==={
last pid: 811; load averages: 1.01, 0.97, 0.67up 0+00:16:12 23:26:26
24 processes: 1 running, 21 sleeping, 2 stopped
CPU states: 0.0% user, 0.0% nice, 0.0% system, 7.9% interrupt, 92.1% idle
Mem: 7524K Active, 9788K Inact, 5812K Wired, 8K Cache, 6336K Buf, 5300K Free
Swap: 300M Total, 300M Free
PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND
811 root 46 0 1916K 1176K RUN 0:00 0.00% 0.00% top
===}
A few seconds after starting:
root@nn:~##uptime
11:30PM up 50 secs, 1 user, load averages: 0.88, 0.22, 0.08
Of course, real LA is less than 0.1.
The same system has another strangeness - `microuptime() went backwards':
==={ /var/run/dmesg.boot
Copyright (c) 1992-2000 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 5.0-CURRENT #0: Sat Sep 9 08:19:58 EEST 2000
[EMAIL PROTECTED]:/usr/src.cr/sys/compile/nn10
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 334092166 Hz
CPU: AMD-K6(tm) 3D processor (334.09-MHz 586-class CPU)
Origin = "AuthenticAMD" Id = 0x58c Stepping = 12
Features=0x8021bf
AMD Features=0x8800
real memory = 33554432 (32768K bytes)
avail memory = 28540928 (27872K bytes)
Preloaded elf kernel "kernel.ko" at 0xc0426000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc04260a0.
K6-family MTRR support enabled (2 registers)
md0: Malloc disk
npx0: on motherboard
npx0: INT 16 interface
pcib0: on motherboard
pci0: on pcib0
isab0: at device 7.0 on pci0
isa0: on isab0
atapci0: port 0xf000-0xf00f at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: at 7.2
pci0: at 7.3
pci0: at 17.0 irq 11
fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: at port 0x60,0x64 on isa0
atkbd0: flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0
sc0: at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: at port 0x378-0x37f irq 7 on isa0
ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode
ppc0: FIFO with 16/16/16 bytes threshold
lpt0: on ppbus0
lpt0: Interrupt-driven port
plip0: on ppbus0
ppi0: on ppbus0
sbc0: at port 0x220-0x22f,0x388-0x38b,0x330-0x331 irq 5 drq 1,0 on isa0
pcm0: on sbc0
unknown: can't assign resources
pca0: at port 0x61 on isa0
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
unknown: can't assign resources
IP packet filtering initialized, divert enabled, rule-based forwarding disabled,
default to accept, logging limited to 100 packets/entry by default
DUMMYNET initialized (000608)
IPv6 packet filtering initialized, default to accept, logging limited to 100
packets/entry
IPsec: Initialized Security Association Processing.
ncp_load: [210-213]
IP Filter: v3.4.9 initialized. Default = pass all, Logging = enabled
microuptime() went backwards (1.3891137 -> 0.596214)
microuptime() went backwards (1.3891137 -> 0.596655)
microuptime() went backwards (1.3891137 -> 0.597078)
microuptime() went backwards (1.3891137 -> 0.597480)
microuptime() went backwards (1.3891137 -> 0.597795)
microuptime() went backwards (1.3891137 -> 0.598094)
microuptime() went backwards (1.3891137 -> 0.598412)
microuptime() went backwards (1.3891137 -> 0.598708)
microuptime() went backwards (1.3891137 -> 0.599019)
microuptime() went backwards (1.3891137 -> 0.599489)
microuptime() went backwards (1.3891137 -> 0.600060)
microuptime() went backwards (1.3891137 -> 0.600484)
microuptime() went backwards (1.3891137 -> 0.600921)
microuptime() went backwards (1.3891137 -> 0.601532)
microuptime() went backwards (1.3891137 -> 0.601965)
microuptime() went backwards (1.3891137 -> 0.602373)
microuptime() went backwards (1.3891137 -> 0.602789)
microuptime() went backwards (1.3891137 -> 0.603218)
microuptime() went backwards (1.3891137 -> 0.603658)
microuptime() went backwards (1.3891137 -> 0.604059)
microuptime() went backwards (1.3891137 -> 0.604479)
microuptime() went backwards (1.3891137 -> 0.604902)
microuptime() went backwards (1.3891137 -> 0.605318)
microuptime() went backwards (1.3891137 -> 0.605743)
ad0: 14664MB [29795/16/63] at ata0-master using UDMA33
(null): failure to execute ATAPI packet command
microuptime() went backwards (1.3891137 -> 0.733477)
microuptime() went backwards (1.3891137 -> 0.733885)
microuptime() wen
Re: cvs commit: src/libexec/uucpd uucpd.c
Hello Eivind Eklund! Sun, Nov 07, 1999 at 14:25:22, eivind wrote about "Re: cvs commit: src/libexec/uucpd uucpd.c" in cvs-commiters@, cvs-all@: > > Just for the record, this is considered a really bad thing, because > > one common error is typing the password when the username is being > > expected. > > > > Of course, in an automated environment without user intervention, > > that's probably not relevant. But I'd rather just remark on it > > anyway. :-) > > I wouldn't expect anybody to do UUCP manually. The standard practise is to use UUCP on network access server with some pass (rlogin, etc.) to real uucp server. When script fails in something (incorrect waitings, modem failures, cable failures...), it can send password when server expects login, and vice versa. > The servers I originally did this change for has about a thousand > customers using UUCP-over-TCP, using various systems. I've not seen > any passwords end up in the log; however, it has made it possible to > contact users with problems, and to see why we continiously got logged > password failures (answer: Some broken client sending 'quit' on the > username prompt before disconnecting). You have quite good phone lines and customers have good cables and ports. In some places it is not standard, but hope ;( > I don't have any religious feeling about this change, and I'm willing > to back it out and keep it as a local change again (the way it has > been for a year or so). I just thought it would be considered an > improvement for other users, too. Possibly it should be turned off by default and turned on in config. -- NVA To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Filesystem deadlock
Alexander N. Kabaev wrote: ANK> The following script reliably causes FreeBSD 4.0-CURRENT (and 3.1-STABLE ANK> as of today) to lookup. 2.2.8 and 3.0-RELEASE are not vulnerable, by the way. ANK> Shortly after this script is started, all disk ANK> activity stops and any attempt to create new process causes system to ANK> freese. No, creating of new process is possible, but no file can be opened. All memory activity does not hang: i.e., top redraws list of active processes. Also, command '( export A=1 B=2 set )' works - that is, fork() works. ANK> While in DDB, ps command shows, that all ten fgrep processes are ANK> sleeping on inode, all xargs are in waitpid and ANK> all sh processes are in wait. In original tests, any process can stop in 'inode' state when it try to open a file. For example, try type 'ps' at another terminal and You can see shell stopped in 'inode' state ;( ANK> #!/bin/sh ANK> for j in 1 2 3 4 5 6 7 8 9 10; do ANK> echo -n $i $j ~~ ;( ANK> nohup sh -c 'while :; do find /usr -type f | xargs fgrep zukabuka; ANK> done' \ >>/dev/null 2>&1 & ANK> echo ANK> done -- -- Valentin Nechayev ne...@lucky.net II:LDXIII/MCMLXXII.CCC To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
