Re: vinum still not working
On Sunday 23 November 2003 23:50, you wrote: Yes. The fix wasn't enough. I was holding off committing until I could test it. Thanks for YOUR commit! :-) All works fine here now... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
vinum still not working
Hello, I just built a new world+kernel after the commit of grogs corrections but I still get: [EMAIL PROTECTED] - ~ 503 # vinum start ** no drives found: No such file or directory -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: grub on -current?
Hi Nate, On Friday 21 November 2003 21:11, Nate Lawson wrote: Is anyone using this successfully? I had to install it from Linux. The grub.conf below works when installed by the Linux grub-install but FreeBSD's port always fails with the below messages. Package: grub-0.92 Yes, I'm using grub but yes, I also installed from Linux. The problem seems to be GEOM, which doesn't allow to write the bootsector to a disk which has mounted filesystems on it. So if you have / on the bootdisk, there's no chance but to boot grub from floppy and install it from there. Ahm, nearly. There seems to be a sysctl (...geom.debug=16 ?) which allows to write the bootsector, but you better ask phk directly - I'm not sure... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: suddenly bind and access to NNTP server (localhost) doesn't work
Hi, On Monday 03 November 2003 15:40, Andreas Klemm wrote: I found the culprit, for my eyes its a problem with ipfw. I'm not sure with your assumption. I also have severe problems with 5.1-CURRENT of Nov-2-2003 but my firewall-rule is working: 00100 76 9542 allow ip from any to any via lo0 My system always panics during shutdown with the 'named'-process, just like Peter reported it in Panics and stuff.. from Sun, 2 Nov 2003 22:48:34 +0100... OK, I *did* read UPDATING, so I portupgraded dns/bind9 but that didn't help. So I used /usr/sbin/named, but the same things happen. I *can* shutdown to singleusermode, umount all filesystems, remount / 'ro' and reboot from there - but the regular 'shutdown -r now' panics with named. I'm no developer, so I go back to current of Okt 29, hoping that this works - my last working current until last Saturday was from Okt 25... Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
On Thursday 17 July 2003 08:14, David O'Brien wrote: I'm willing to commit it as such, but I'd like to hear more people's opinion. What I found so far: - gvim 6.2.21 works under 'twm' - gvim 6.2.21 works under 'kde 3.1' with SESSION_MANAGER unset - gvim 6.2.21 works under 'kde 3.1' if running on a remote machine tunneled through ssh's X11-redirection as reported by others: - gvim 6.2.21 works without patch 015 I looked at patch 015 but I'm not familiar with X11 SessionManagerProtocol - perhaps some others are able to analyze the correctness of that patch... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) PGP-Key at pgp.mit.edu and wwwkeys.de.pgp.net ID: 0xDDFB0A5F ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: several background fsck panics
Terry Lambert wrote: The issue with the repeating background fsck's is important. I suggest a counter that gets reset to zero each time the FS is marked clean by fsck, and incremented each time the background fsck process is started. When this counter reaches a predefined value (I sugest a command line option to background fsck, which defaults to 3, if left unspecified), then the fsck is automatically converted to a foreground fsck. This counter would be recorded in the superblock. This sounds like a good idea! I vote for a counter of 2... :-) Also I suggest to mention as clearly as possible, that operating Soft Updates with Write Cache enabled is kind of 'out of specs'. This cannot work when crashing! (As you stated clearly!) So I'm also voting for 'WC disable' for any kind of disks. SCSI-disks don't need it because of Tagged Queuing and only those ATA-Disks that *have* TQ can/should be operated 'the fast way' - hoping that Soeren gets it working again... :-/ -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: softupdates write cache ata tags topic
Hi, Is it safe to use softupdates + write cache + ata tags (IBM disk)? The summary of *my* experience and knowledge is: It is considered *unsave* to use Soft Updates with WriteCache enabled. I consider it unnecessary to use WriteCache if TaggedQueuing is enabled and working. (The performace gain of WriteCache and TaggedQueuing is more or less the same, the combination of both adds less than 10% of performance and you shouldn't use Soft Updates any more) Soft Updates alone add a huge amount of performance. So I recommend to use Soft Updates with Tagged Queuing enabled. -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ATA Tagged Queuing working again?
Hi Soeren, Hi all, it seems to me that ATA TQ is working again with -current as of yesterday :-) My disk is on atapci0: VIA 82C686b UDMA100 controller port 0xc000-0xc00f \ at device 7.1 on pci0 It's an ad0: 43979MB IBM-DTLA-307045 [89355/16/63] at ata0-master UDMA100 Even if it's obviously not reported as TAGGED, it seems to work as such: 'atacontrol cap 0 0' reports: ATA channel 0, Master, device ad0: ATA/ATAPI revision5 device model IBM-DTLA-307045 serial number YMDYMH21528 firmware revision TX6OA50C cylinders 16383 heads 16 sectors/track 63 lba supported 90069840 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes no read ahead yes yes dma queued yes yes 31/1F SMART yes no microcode download no no security yes no power management yes yes advanced power management yes no 0/00 automatic acoustic management yes no 254/FE 128/80 So 'write cache' is disabled and 'dma queued' is enabled, right? At least my 'standard test' (which is a 'tar cvf /dev/null /disk/ports') is not able any more to switch the disk to PIO-Mode - which I tried repeatedly ;-) The only thing I saw were 1,2 stops of about 500ms during the listing of the tar-command but nothing worse happened. With earlier Kernels this indicated a soon lock and switch to PIO... Fine! I hope this stabilizes... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Grub 0.92 fails to recognise disks on FBSD5
Hi all, I'm fighting with the same problem and found that grub *does* recognize the disks if started with '--read-only'... That fits perfectly to the following paragraph found in the 5.0-RELEASE Errata: The geom(4)-based disk partitioning code in the kernel will not allow an open partition to be overwritten. This usually prevents the use of disklabel -B to update the boot blocks on a disk because the a partition overlaps the space where the boot blocks are stored. A suggested workaround is to boot from an alternate disk, a CDROM, or a fixit floppy. I can happily boot -current with grub - booting isn't the problem, installing it is the problem. And I installed grub from my 4.7-STABLE installation... (happy to have one :-) Grub seems to open disks/slices r/w and refuses to know them if that's not possible. I, personally, would say that's a bug of grub but that doesn't help here. It even doesn't help, if you run 5.0/-current on your base disk because you can't write the MBR anyway. My question to 'phk' is, if he (or anybody else) has or at least could imagine a solution for this problem. Nothing against 'booteasy', it does the job - but it looks ugly :-) And I can't imagine that the majority of FreeBSD-Users all have a bunch of disks in their systems - especially if I think of the giant sizes of HDs nowadays... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) + UFS2
Hello :-) I just (20:00 CET) did a new 'make world' on my current-slice and I'm happy to report that dump(8) is working perfectly now, even on UFS2. It's performing 'snapshots' on mounted filesystems for backup and additionally seems to be somewhat (at least) faster... Great Job! Thanks a lot! -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
cdrecord/SCSI problems
Hi all, I just found problems writing audio-CDs under -current FreeBSD 5.0-CURRENT #3: Thu Nov 28 21:59:11 CET 2002. These problems don't occur writing ISO-(Data-)files nor do they occur writing audio-CDs or Data-iso-files under -STABLE. I append the standard-output of the 'cdrecord'-command below, SCSI-Controller is a LSI Logic U-SCSI model using the sym-driver. 'dmesg | grep sym1' says: sym1: 875 port 0xe000-0xe0ff mem 0xe3003000-0xe3003fff,0xe3002000-0xe30020ff irq 15 at device 10.0 on pci0 sym1: Symbios NVRAM, ID 7, Fast-20, SE, parity checking sym1: open drain IRQ line driver, using on-chip SRAM sym1: using LOAD/STORE-based firmware. sym1: SCAN AT BOOT disabled for targets 8 9 10 11 12 13 14 15. sym1: SCAN FOR LUNS disabled for targets 0 1 2 3 4 5 6 8 9 10 11 12 13 14 15. (noperiph:sym1:0:-1:-1): SCSI BUS reset delivered. sa0 at sym1 bus 0 target 4 lun 0 da4 at sym1 bus 0 target 0 lun 0 cd1 at sym1 bus 0 target 5 lun 0 cd0 at sym1 bus 0 target 3 lun 0 ... where 'cd1' is the YAMAHA CRW4416 drive. And here is the cdrecord-session: root@current - /raid/audio/tmp 111 # cdrecord -dummy dev=1,5,0 -dao -useinfo -text *.wav pregap1: -1 Cdrecord 1.11a39 (i386-unknown-freebsd5.0) Copyright (C) 1995-2002 Jörg Schilling scsidev: '1,5,0' scsibus: 1 target: 5 lun: 0 Using libscg version 'schily-0.7' Device type: Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor_info: 'YAMAHA ' Identifikation : 'CRW4416S' Revision : '1.0j' Device seems to be: Generic mmc CD-RW. Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC SWABAUDIO Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R Starting to write CD/DVD at speed 4 in dummy SAO mode for single session. Last chance to quit, starting dummy write0 seconds. Operation starts. SAO startsec: -11615 cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error CDB: 2A 00 FF FF D2 A1 00 02 9A 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 21 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 08 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x21 Qual 0x00 (logical block address out of range) Fru 0x0 Sense flags: Blk 0 (not valid) resid: 63936 cmd finished after 0.003s timeout 200s write CD-Text data: error after 0 bytes cdrecord: Could not write Lead-in. Are these error messages of any use for anybody? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump(8) + UFS2
On Saturday 30 November 2002 23:24, you wrote: On Sat, 30 Nov 2002, Manfred Antar wrote: I guess dump is not ready for UFS2 I just have made dump and restore of my 3GB UFS2 /usr partition and did not experience any problems with that. Working on -CURRENT from Nov 24th. Sure you dumped an UFS2 filesystem? Here's my try: root@current - /root 104 # uname -a FreeBSD current.best-eng.de 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Thu Nov 28 21:59:11 CET 2002 [EMAIL PROTECTED]:/disk/obj/usr/src/sys/CURRENT i386 root@current - /root 103 # dump 0af /dev/nsa0 /usr DUMP: Date of this level 0 dump: Sat Nov 30 23:50:24 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da3s1g (/usr) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: SIGSEGV: ABORTING! Speicherschutzverletzung (core dumped) Or is it a SCSI-problem? Did you dump from an ATA or SCSI-Disk? To an ATA or SCSI tape-device? Astonishing... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Another 'buildworld' showstopper
Hello, With sources few minutes old (as well as with sources approx. 3h old): === gnu/usr.bin/groff/tmac /usr/src/gnu/usr.bin/groff/tmac/Makefile, line 2: warning: duplicate script for target -s ignored [... 12 times repeated] make: don't know how to make doc-common-s. Stop *** Error code 2 Stop in /usr/src/gnu/usr.bin/groff. *** Error code 1 Stop in /usr/src. *** Error code 1 PS: ... and it's an i386 and no alpha (see UPDATING) -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.7-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Actual probs with 'ipfw'
Hi, I updated my kernel now just like told in the last HEADSUP and hesitate to do a 'make installworld' as also mentioned there... Now, during boot 'ipfw' complaines: ipfw: size mismatch (have 64 want 1064) ipfw: size mismatch (have 52 want 40) ipfw: size mismatch (have 52 want 40) This happens every time I run 'sh /etc/rc.firewall open'. Not to mention, that the firewall is closed perfectly :-/. I didn't run 'mergemaster' because of no installworld. Is that the problem? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 5.0-CURRENT To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Actual probs with 'ipfw'
On Saturday 26 October 2002 21:48, you wrote: No, the problem is that you need to installworld to have an updated ipfw(8) binary. Confirmed! Thanks a lot! PS: So the HEADSUP-strategy has its limitations... ;-) -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.7-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Actual probs with 'ipfw'
On Saturday 26 October 2002 22:17, you wrote: You did not reboot to single user mode to installworld. No need to run ipfw with the new kernel before installworld. -current readers are expected to know that. Right! What I meant was: For this reason, you probably want to delay an installworld until you are comfortable that your newer kernel builds are satisfactory. from: Message-ID: [EMAIL PROTECTED] But my new kernel build *is* satisfactory now :-) -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.7-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
Terry Lambert wrote: Yes, soft updates does nothing of user data, it is a metadata technology. Journalling is implementation dependent; not all JFS implementations will journal data which is not metadata, so your results would depend on the JFS. I think you are not correct here. If I understand Kirks paper right, Soft Updates do a sorting/nesting of data and metadata within the buffer cache. My knowledge is, that most of the journaling implementations do metadata journaling and do not guarantee data consistency (ext3 with data=journal is the only exception I know of), whereas SU *does* guarantee data consistency (admittedly with a time lag) because of that nesting from data with metadata. I'm far away from beeing able to follow this discussion in every detail, but please correct me if I'm wrong... -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.7-RC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Journaled filesystem in CURRENT
If I may add a comment here... You already *have* a kind of journaled filesystem for some time now. Please read Soft Updates vs. Journalling Filesystems from M.K. McKusick (www.mckusick.com). I'm really sad if see the efforts done especially for porting JFS to FreeBSD, which has already under Linux a more than poor performance. The only reason for porting JFS is IMHO to be able to mount JFS Volumes under FreeBSD - if that's worth the effort... Why begging for 'Journaling' if you have 'Journaling next generation'? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.7-RC To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: xdm-Problems with PAM
Am Dienstag, 13. August 2002 14:42 schrieb Alexander Leidinger: On Mon, 12 Aug 2002 22:06:59 +0100 David Malone [EMAIL PROTECTED] wrote: On Mon, Aug 12, 2002 at 10:19:00PM +0200, Matthias Schuendehuette wrote: Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? I recompiled xdm and the problem went away - I'm not sure if I should have thought about the problem more carefully. If xdm was compiled with old-pam, recompiling it is the only thing which helps, if it is already compield with new-pam, then I don't know what happens here. Ahemm... I must admit, I installed XFree4.2 from the 4.6-CDs... That obviously doesn't work - at least 'xdm' can't work, the rest of X seems to be OK. It's a pity - I can't download and compile the whole X-stuff with a only partly working i4b under -current on a 2 GB disk... Thank you both for your replies - Matthias -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.6-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
xdm-Problems with PAM
Hi, I set up xdm on my -current machine last Saturday and have the same problems still with todays (12.Aug) -current: When I try to login with 'xdm', the following errors come up: Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_nologin.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_nologin.so: Undefined \ symbol _pam_verbose_error] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_nologin.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_unix.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_unix.so: Undefined \ symbol _pam_verbose_error] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_unix.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_opie.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_opie.so: Undefined \ symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_opie.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_opieaccess.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_opieaccess.so: \ Undefined symbol _pam_verbose_error] Aug 12 18:20:02 current : adding faulty module: \ /usr/lib/pam_opieaccess.so Aug 12 18:20:02 current : unable to dlopen(/usr/lib/pam_lastlog.so) Aug 12 18:20:02 current : [dlerror: /usr/lib/pam_lastlog.so: Undefined symbol _openpam_log] Aug 12 18:20:02 current : adding faulty module: /usr/lib/pam_lastlog.so 'Known behaviour' or real problems? -- Ciao/BSD - Matthias Matthias Schuendehuette msch [at] snafu.de, Berlin (Germany) Powered by FreeBSD 4.6-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Am Donnerstag, 18. April 2002 16:44 schrieb Søren Schmidt: It seems Terry Lambert wrote: Søren Schmidt wrote: It seems Terry Lambert wrote: My other hunch is that there will need to be a channel reserved for reset commands to be queued to the disk, so that you can queue more commands to it later (e.g. can't connect to send the reset because of the already disconnected commands in progress). Terry, read the ATA spec, it doesn't work that way, tags on ATA is very different from tags on SCSI, and beside a reset is not a command, but a bit in a HW port.. I didn't mean for the reset itself, I meant for the process. You can't take back writes that are in progress and not acknowledged, in order to retry them after the reset, so as to not lose data. Oh yes you can, the ATA driver does just that in case of the drive loosing its marbels. Does that mean that the driver isn't aware of the 'tags-problem'? If I understand you right, it should be possible to reset the drive and continue, maybe without tags or at a reduced UDMA-Speed or whatever actions seem appropriate... ...ahh, I mean, the driver *does* take an action (it/he(?) switches back to PIO4), but why is any UDMA-Mode no longer usable afterwards? Is the drive been reset or just switched back? What is the impact of a reset compared to a switch back? Well, just my thoghts, I'm no specialist at all -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Am Donnerstag, 18. April 2002 17:54 schrieb Terry Lambert: I wish someone who is having the problem would try the three hacks I suggested, and report back. I personally can't reproduce the problem here, either. Ok, ok... ;-) I start *now*. I just compiled a new -current world (...puhh) and kernels are in place... ...'till later. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Am Donnerstag, 18. April 2002 17:54 schrieb Terry Lambert: I wish someone who is having the problem would try the three hacks I suggested, and report back. I personally can't reproduce the problem here, either. So: I changed line 186 in sys/dev/ata/ata-disk.c from adp-num_tags = atadev-param-queuelen; to adp-num_tags = 0x10; which is roughly the half of the reported queuelenght (which is 0x1F). And, Terry, I can't avoid to disappoint you... there's absolutely *no* change in the behaviour of the new kernel :-( As I've reported earlier, the writecaching also makes no difference as does (not) changing the UDMA-speed (with 'atacontrol'). If you pretend on it, I'll change the DMA-speed with the IBM-tool, but I think we can do without it... (urghh, I would have to change to Windoze :-/ ) Sorry for the bad news, but... I think, we'll wait for Soren's commit tonight. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Hello, Am Mittwoch, 17. April 2002 03:14 schrieben Sie: Matthias Schuendehuette wrote: I used 'atacontrol' to read the number of tags allowed: it is 31 (0x1F). Perhaps Soren could tell me how to force it to, say, 0x10? You have to modify the source code in ~line 180 of /sys/dev/ata/ata-disk.c. Well, thanks for the hint. I just have to wait until I get a new 'current'-world... yesterday it didn't compile and because of an, say, 'indisposition' of vinum (I changed another slice on a vinum-disk, so it dislikes the whole plex :-^ ) I lost my current /usr/obj... Then I tried various combinations of UDMA100/66/33 and wc=0/1 - it nearly doesn't change anything. BTW: I switched UDMA speed using 'atacontrol'... After the first switch to PIO4, I umounted the filesystem and switched back to UDMA33 for instance - I couldn't even *mount* the filesystem again! [...] My hunch, which is why I suggested decreasing the number of tags seen by the driver, is that the tagged queues are over used, and this locks the disk up. [...] Yes, I understand this (I for myself had already your 'off-by-one'-suspicion - it's obvious if one sees the error message) and I'll test it ASAP. What I was wondering yesterday before I fell asleep is that the disk is obviously not able to recover from this error - even if the error condition is no longer valid due to the switch to PIO-mode. *Any* DMA-mode is no longer useable. I don't know if it's an attribute of these disks or an issue solvable by a/the driver. I would expect to be able to do a software reset of the drive like with SCSI, but I'm a bit biased against ATA (vs. SCSI) because of the opinion/argues of a very knowledgeable guy here in the german newsgroup (former core team member ;-), so I wouldn't be surprised if that's not possible or not specified. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
Hi Terry and you all, On Tuesday, 16. April 2002 01:48 you wrote: [...] As I said: it could be drive settings unrelated to the code itself being correct. I've given three suggestions to verify this, one way or the other: 1)Control the drive DMA speed down 2)Pretend the maximum tagged command queue depth is smaller than it is 3)Toggle the write caching on the drive I used 'atacontrol' to read the number of tags allowed: it is 31 (0x1F). Perhaps Soren could tell me how to force it to, say, 0x10? Then I tried various combinations of UDMA100/66/33 and wc=0/1 - it nearly doesn't change anything. If WC was enabled, I saw errors concerning tags 0 *and* 1, whereas without write caching only tag=0 was mentioned. I should say that my simple test was a 'tar cvf /dev/null /usr/ports' with /usr/ports on an ATA-partition. Why *Write*Caching has any influence here...??? What was consistent thru all test was, that the disk operates quite some time until the error occures the first time. After that, it is not possible to access the disk in UDMA-Mode any more, regardeless *which* UDMA-Mode it is. 'Quite some time' means approx. 50% of /usr/ports in the above mentioned 'test'. After the first switch to PIO4, I umounted the filesystem and switched back to UDMA33 for instance - I couldn't even *mount* the filesystem again! But w/o Tagged Queuing the disk operates flawlessly, so I'm a bit in doubt, if the errors with WD-disks have the same source... but may be. So far - but still some data: CPU: AMD Duron(tm) processor (801.82-MHz 686-class CPU) real memory = 268369920 (262080K bytes) pcib1: VIA 8363 (Apollo KT133) PCI-PCI (AGP) bridge \ at device 1.0 on pci0 /* It's an EPoX 8KTA2 MoBo */ atapci0: VIA 82C686 ATA100 controller port 0xd000-0xd00f \ at device 7.1 on pci0 atapci0: Correcting VIA config for southbridge data corruption bug ad0: 43979MB IBM-DTLA-307045 [89355/16/63] at ata0-master UDMA100 ...and 'atacontrol cap 0 0' says: ATA channel 0, Master, device ad0: ATA/ATAPI revision5 device model IBM-DTLA-307045 firmware revision TX6OA50C cylinders 16383 heads 16 sectors/track 63 lba supported 90069840 sectors lba48 not supported dma supported overlap not supported Feature Support EnableValue Vendor write cacheyes no read ahead yes yes dma queued yes yes 31/1F SMART yes no microcode download no no security yes no power management yes yes advanced power management yes no 0/00 automatic acoustic management yes no 254/FE 128/80 That's it. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA errors on recent -current
I'm very sorry if I will be a bit unpolite, but I have to mail the following statement concerning the DTLA-Disks and FreeBSD: It may be all true and horrible, but - I still have an old FreeBSD Test-Installation (45GB are big enough :-) with a 4.4-STABLE as of Okt 23, 2001... It boots off the DTLA, uses tagged-queuing and connects using UDMA100... ... and doesn't have any problems!! So, to bring some of you down to earth again, the DTLA may be a horrible disk and I'm one of the last to praise ATA at all (My machine has two SCSI host adaptors, five SCSI-Disks and several other SCSI Devices), but it once worked! I really, really don't want to blame Søren, he's doing a great job and everybody, who makes something makes occasionally some errors, but (at least for me) it doesn't seem to be a fundamental technical problem, because *it once worked* - sorry, but it's true. And maybe it isn't related to tagged queuing and the DTLA at all - if I correctly understand Giorgos' mail... -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make world stops...
Hi everybody, because noone mentioned it so far... : c++ -O -pipe -march=k6 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/preproc/eqn -I. -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/include -D__FBSDID=__RCSID -fno-rtti -fno-exceptions -static -o eqn eqn.o main.o lex.o box.o limit.o list.o over.o text.o script.o mark.o other.o delim.o sqrt.o pile.o special.o /raid/obj/usr/src/i386/usr/src/gnu/usr.bin/groff/src/preproc/eqn/../../../src/libs/libgroff/libgroff.a make: don't know how to make neqn. Stop *** Error code 2 Stop in /usr/src/gnu/usr.bin/groff/src/preproc. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usb lpt borked?
Am Samstag, 6. April 2002 15:10 schrieb Alexander Leidinger: On 6 Apr, Josef Karthauser wrote: Only my USB mice does something bad, it hangs the system hard on shutdown. Try this which Scott Long submitted a few days ago: Index: uhci.c === RCS file: /usr/home/ncvs/src/sys/dev/usb/uhci.c,v retrieving revision 1.104 diff -u -r1.104 uhci.c --- uhci.c 1 Apr 2002 22:03:37 - 1.104 +++ uhci.c 5 Apr 2002 08:17:03 - @@ -2051,6 +2051,7 @@ xfer-pipe-intrxfer = 0; } uhci_abort_xfer(xfer, USBD_CANCELLED); + usb_transfer_complete(xfer); } /* Close a device interrupt pipe. */ Works for me as well. I can't say nothing about usb-printing but the mouse issue seems to be solved with this patch. I someone asks me - please commit it ASAP -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
'moused' freezing system
Hello, I encountered a problem when using 'moused' on /dev/ums0: On shutdown or if 'moused' gets killed manually, the system freezes completely and silently, no further shutdown is possible, only the resetbutton operates... This does not happen if I'm using /dev/psm0. At least, I can enjoy background-fsck on every startup... ;-) I have a VIA 83C572 USB controller. -- Ciao/BSD - Matthias Matthias Schuendehuette [EMAIL PROTECTED], Berlin (Germany) Powered by FreeBSD 4.5-STABLE To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
