Re: usb flashkey disk copy error
On Sun, 7 Sep 2003, John-Mark Gurney wrote: Hmmm. I just thought of something. Now is the data corrupt still correupt on another system? What I mean is did the data get written properly, but just isn't being read back from the media correctly. Unless you are coping a file larger than memory size, the cmp just pulls it from memory, not from the media. The umount/mount forces a flush of the cache, and so attempts to read from the media. I'm also suffering (probably) the same problem. In my case, the drive is a Sony memory stick slot on a PCG-U1 laptop; connection to the system is via OHCI. For my usage, it's definitely a _read_ phenomenon - I'm creating images on the memory stick in my P800 phone/camera and trying to read them via an msdosfs mount on the laptop. Retrieving them via Windows demonstrates that the images are good; reading them under FreeBSD shows them corrupt at a _file_ offset of 4096 decimal. I tried copying the whole filesystem with 'dd', then using 'mdconfig' to mount the resulting image, eg.: dd if=/dev/da0s1 of=stickfile4 bs=32k mdconfig -a stickfile4 mount -t msdos /dev/md0 /mnt With a blocksize to 'dd' of 512, 8k it worked fine (no corruption); with a block size of 100k the files were corrupt (but in different places compared to mounting the memorystick directly). Using a block size of 32k, it copied for a minute or so and then the machine hung totally (repeatable across two attempts). In terms of dates, I'm now running with -current of 4th september; this problem was also present in a kernel built on August 22nd. It was working OK with whatever kernel I was running on 23rd May (based on timestamps on some files I wrote on the PC). In fact, up until around that time this setup didn't work at all: the internal OCHI port that connects to the memory stick slot always reported 'device problem' and wouldn't find the device (the second OHCI controller that is brought out to conventional sockets worked OK). One system update that I did suddenly made everything work, then a month or two later this problem arrived. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: L440gx+ serial BIOS needs text mode
On Mon, 3 Feb 2003, Lucky Green wrote: However, the Intel L440gx+ motherboard I have (it came in a VA Linux rackmount) seems to have a separate CPU performing all kinds of monitoring tasks, watchdog, etc, so I was hoping this separate CPU was actually performing the serial console task. As I read it on page 64 of the manual (download from Intel), the second serial port is actually connected through a multiplexer to the Baseboard Management Controller (Dallas 82CH10) in my configuration. ftp://download.intel.com/support/motherboards/server/l440gx/254151-003.p df I've used several generations of these intel boards, though not the exact one which you have, most recently the se7500wv2. All of them are more conventional than it might appear: - The 'screen scraper' for serial access to the BIOS works from software on the main (i386) CPU. The earlier machines didn't have on-board video, so mapped in some ordinary RAM to the video area if you ran them without a video card fitted; later machines have video hardware and the console redirection polls this RAM. Either way, it's BIOS software generating ANSI escapes out of the ordinary serial port, and this stops when the OS boots. - The management CPU sits between the external serial port connector and the UART in the main CPU's chipset. Hence the OS running on the main CPU always thinks it's got a standard COM port, it's just a question of whether data sent to/from that port makes it to the external connector or gets subverted by the management CPU. - On the latest machines featuring 'serial over LAN', you can persuade the management CPU to subvert the serial port and pass the data over one of the ethernet ports. This seems to use a proprietary protocol, but if you have one Windows machine somewhere with the Intel management software loaded on it, you can use that to proxy the protocol for any number of managed machines - ie. telnet to port 623 on the Windows machine, then connect back to the target machine and get attached to the serial console (and so get a FreeBSD login, if that's what is running on COM2). - Medium-aged machines seem to have all the hardware to subvert the serial and ethernet ports, but won't do serial redirection apart from controlling the BIOS. Upgrading the BMC software didn't help on the machine I had in this category. Disclaimer: the above is just from playing with the machines and reading the documentaton, so I may be wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OHCI patch - please test [was Re: USB issues with Apollo KT133Amobo]
On Thu, 5 Dec 2002, Josef Karthauser wrote: If you're an ohci user can you please test this patch out for inclusion in 5.0. I need to know that it doesn't break anything - the reports are that it fixes broken ohci :). I've been running it since you posted the patch a couple of days ago. I thought it had cured my problem with plugging/unplugging devices causing the ports to get into an invalid state (requiring a reboot to restore operation), but I took the patch out again and couldn't reproduce the problem, so it must have been fixed by one of the other recent changes that I hadn't noticed. Anyhow, the new patch certainly doesn't seem to do any harm. The one remaining problem I have with the OHCI on this machine (a Sony PCG-U1 laptop) is with the internal memory-stick controller, which I believe is connected to ohci0: (the two externally-accessible ports are connected to ohci1:). The driver can evidently see something connected to ohci0: but it fails to probe correctly: ohci0: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe8102000-0xe8102fff irq 9 at device 15.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: AcerLabs M5237 (Aladdin-V) USB controller on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered --- Long pause here --- uhub0: device problem, disabling port 1 8x other devices here --- ohci1: AcerLabs M5237 (Aladdin-V) USB controller mem 0xe-0xe0fff irq 9 at device 20.0 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: AcerLabs M5237 (Aladdin-V) USB controller on ohci1 usb1: USB revision 1.0 uhub1: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: FreeBSD 5.0 Developer Preview #1 Now Available / diskless booting
On Wed, 24 Apr 2002, M. Warner Losh wrote: In message: [EMAIL PROTECTED] David O'Brien [EMAIL PROTECTED] writes: : On Tue, Apr 23, 2002 at 12:19:58PM -0400, Robert Watson wrote: : diskless_root_readonly=NO # Make it YES for readonly : : good. What's wrong with the current root_rw_mount knob? It works just fine. The original complaint was that Danny's patches _assume_ that the root is going to remain R/O and just provide two ways of populating the MFS /etc, rather than allowing for the case where the MFS /etc isn't required at all. (actually, this is just reversing a recent obrien improvement to rc.diskless1 that made the MFS /etc conditional - it's still automatic in -stable and has been for a long while). There isn't a problem with controlling the root mount; diskless_root_readonly is a solution to a non-problem. The real problem is that (in the case where you want it) there is no one good way of constructing the MFS /etc - there are lots of bad ways, various of which have been committed to rc.diskless1 at different times, and still more used privately: 1) Create an MFS mounted on an arbitrary mountpoint, then use mount_null to install it over /etc when it's been populated. This was the original version when the support for read-only root appeared in rc.diskless back in 1999 (3.2-RELEASE). Gave problems because null mounts didn't (still don't?) work very well - mmap() caused panic for example. 2) Copy the files out of /etc into /tmp, then mount the MFS directly on /etc and copy the files back again. This appeared in 2001 (4.3-RELEASE) 3) Avoid the double copy on each boot by requiring the administrator to keep a copy in /conf/default/etc that can be copied directly to an MFS mounted on /etc. This appeared a couple of months later (4.4-RELEASE). 4) Small performance improvement on 3) - use a gzipped CPIO archive if available, rather than copying lots of small files which can be slow over NFS. This has just recently been committed to -stable by Luigi. 5) Danny's solution: Mount the MFS on /conf/etc, then use unionfs mounts to install it over /etc. Does unionfs work any better than mount_null? 6) My solution: Mount a second instance of the root FS on /conf/default then copy as in 3). Avoids maintaining two copies of /etc, but only works on NFS and doesn't solve the performance problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: what if/diskless booting
On Wed, 24 Apr 2002, Danny Braniss wrote:
i modified libstand/bootp.c to place all the tags - that dhcp provides - in
the kernel
environmet, so that they can be used later - eg in rc.diskless1.
what if:
we place the rc.conf[.local] there?
in the dhcpd.conf:
option rc-conf 132.65.16.100:/d/4/etc/rc.conf
and so - automagicaly -
`kenv rc.conf.diskless_root_readonly`
or
kenv | grep rc.conf | sed 's/rc.conf.//' rc.conf
Note that Luigi has recently committed something similar to create the
sysctl kern.bootp_cookie (see /sys/nfs_client/bootp.c rev 1.36).
I have also been doing the same thing for some time, but the difference in
my version is that I use four separate DHCP options (133,134,135,136 at
present, though this isn't important) and concatenate their together onto
the end of the (MFS copy of) /etc/rc.conf from rc.diskless1.
The reason for using four options is that in the DHCP configuration there
are a number of different scopes in which you can put the option
assignments, all of which are potentially useful for diskless
configuration options.
For example, in our setup we have some things that need to be set
per-subnet (eg. which servers to use), some that need to be per group{} of
machines in the dhcpd.conf (eg. we have one group of 486-class machines
that are pure X-terminals, and another of more powerful machines which are
allowed to run more services locally), and finally there are some options
that need to be set per-machine (eg. which machines need to run lpd
because they have a printer attached). Each scope gets its own DHCP
option, and then they are all concatenated together onto the end of
rc.conf.
Before implementing this scheme, we tried to use the /etc/conf/ipaddr
scheme, but this didn't really scale well. We started with just two
classes of hardware, so had two /etc/conf/{IBM,COMPAQ} directories with
symlinks for each of the machines of that class, but then as the network
expanded we needed per-subnet configuration and the /etc/conf/${ipba}
scheme didn't work as we still needed the per-machine-class configuration
too. Then we started adding local printers and we now had
/etc/conf/{IBM-net10,COMPAQ-net10,IBM-net11,COMPAQ-net11,IBM-net10-printer}
etc and then we got some new hardware that wasn't quite the same...
With the new scheme, everything is configured in just one place and
adding a new machine or a new per-subnet service is easy.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
USB - bulk data scheduling in UHCI
The current UHCI driver constructs the bulk transfer queue as a simple
list with a 'terminate' marker on the end. This means that the bulk queue
runs only once per frame period. This is OK for devices with large input
buffers, but in the case of a large transfer to a device with a small
input buffer, it limits the throughput to 1 buffer per frame time (nominal
1ms). In the case of the hardware I am using, the buffer is 128 bytes, so
I only get 128000 bytes/sec throughput with the UHCI driver, compared to
over 20 bytes/sec with OHCI.
If the UHCI driver arranges the bulk transfer queue as a circular list,
transfers will be retried repeatedly in what would otherwise be wasted
time at the end of the frame; this is similar to what OHCI does. In fact
in my application the patched UHCI driver comes out slightly better than
OHCI (though this may be other factors like CPU speed).
The patch to do this appears to be very simple (this diff is against
-stable as my -current machine is OHCI, but the code is identical in
-current).
Index: uhci.c
===
RCS file: /repository/src/sys/dev/usb/uhci.c,v
retrieving revision 1.40.2.7
diff -c -r1.40.2.7 uhci.c
*** uhci.c 31 Oct 2000 23:23:29 - 1.40.2.7
--- uhci.c 15 Dec 2001 23:19:17 -
***
*** 371,377
bsqh = uhci_alloc_sqh(sc);
if (bsqh == NULL)
return (USBD_NOMEM);
! bsqh-qh.qh_hlink = LE(UHCI_PTR_T); /* end of QH chain */
bsqh-qh.qh_elink = LE(UHCI_PTR_T);
sc-sc_bulk_start = sc-sc_bulk_end = bsqh;
--- 371,378
bsqh = uhci_alloc_sqh(sc);
if (bsqh == NULL)
return (USBD_NOMEM);
! bsqh-hlink = bsqh; /* Circular QH chain */
! bsqh-qh.qh_hlink = LE(bsqh-physaddr | UHCI_PTR_Q);
bsqh-qh.qh_elink = LE(UHCI_PTR_T);
sc-sc_bulk_start = sc-sc_bulk_end = bsqh;
***
*** 890,896
DPRINTFN(10, (uhci_remove_bulk: sqh=%p\n, sqh));
for (pqh = sc-sc_bulk_start; pqh-hlink != sqh; pqh = pqh-hlink)
#if defined(DIAGNOSTIC) || defined(UHCI_DEBUG)
! if (LE(pqh-qh.qh_hlink) UHCI_PTR_T) {
printf(uhci_remove_bulk: QH not found\n);
return;
}
--- 891,897
DPRINTFN(10, (uhci_remove_bulk: sqh=%p\n, sqh));
for (pqh = sc-sc_bulk_start; pqh-hlink != sqh; pqh = pqh-hlink)
#if defined(DIAGNOSTIC) || defined(UHCI_DEBUG)
! if (pqh == sc-sc_bulk_end) {
printf(uhci_remove_bulk: QH not found\n);
return;
}
Re: Lucent Orinoco Gold PCCard?
On Fri, 8 Dec 2000, Darryl Okahata wrote: I wrote: Also, there are other alternatives to the AirPort (which is closer to $299 than $399). One is the Buffalo AirStation (around $280-$340, I forgot to mention that the AirStation supposedly supports roaming between access points. I haven't tried it, though. Almost all APs support roaming, because they'd have to go out of their way to prevent it: roaming is controlled from the client end. Most clients seem to just implement the "wait until contact is lost with the current AP then scan for a new one" scheme, though cleverer approaches are possible. Roaming between AirPort and AirStation APs certainly works. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD Installations
On Fri, 17 Mar 2000, Forrest Aldrich wrote: I was also curious about what people do to keep a fleet of FreeBSD machines up-to-date with CVSup and buildworld. I can't imagine manually going to more than 100 machines and doing the same thing manually... how time consuming. To summarize again, we are deploying status monitoring machines into POPs, across the US. Those machines are identical in terms of hardware, et al. We were hoping to find a means by which to streamline the installation process, such that we could create (say) custom boot floppies where you'd input minimum information (IP address, hostname, domain, etc.) and it would then go off and perform the installation (from fdisk, newfs... to editing packet filters appropriately, which make require a "template" of sorts). If the job they are doing is fairly simple, and they have (or could have) plenty of RAM, have you considered scrapping the disc drives and having a CD-boot system? Although CD drives are not very reliable for heavy-duty use, you should be able to arrange that the working set gets loaded at start-up and the CD is then idle in all normal use - this may "just work" through normal caching, or you may need to copy active files onto an MFS filesystem (you'll need an MFS for various things anyhow). This has the advantage over pico-BSD style installations that you can fill the rest of the CD with a fairly complete FreeBSD installation: in normal use the CD drive is idle, but you have the full set of tools available for use on rare occasions when they are needed. Obviously the machines need to pick up their identities from somewhere, as you want to just duplicate a stack of identical CDs. If the machines can rely on their environment, DHCP is the obvious way to go; if not, one technique I've used is to key it on the MAC address of the ethernet card (in /etc/rc I pick up the MAC address with ifconfig and then have a big case statement to set up the different characteristics of the machines). Obviously this doesn't suit every application, but I have found it highly advantageous when I want to put down a BSD machine in a location with no local BSD skills to fix things if they go wrong. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /bin/sh Exec format error
On Sat, 2 Oct 1999, Matthew Dillon wrote: Also, when all else fails try booting from a FreeBSD CD. Altneratively it may be possible to boot the normal kernel and use a FreeBSD CD as root by typing 'boot /kernel -C' (or -c, I forget which). It's -C Note however that -C is presently broken in 3.x - needs the changes at revision 1.19 of /sys/boot/i386/libi386/bootinfo.c merged from -current to make it work again. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-Current, netscape halts system
On Sun, 24 Jan 1999, Jordan K. Hubbard wrote: I really don't understand the problems that everyone is having, myself. I've been running netscape (communicator 4.5) in -current for ages now and just switched to 4.0 without any problems. My netscape still continues to function just fine and has never crashed any of my system so much as once. Why the wide disparity in experience, I wonder? One variable may be available memory. On my system, with default datasize limit of 16M from login.conf, Netscape coredumps very frequently. With datasize unlimited, Netscape eats all the available swap (this system is 64M real 128M swap) and kills the system that way. I currently run Netscape with datasize set to 64M, pending a new disc for more swap! In this configuration, Netscape either coredumps or starts behavhing oddly about once every 3 days, but at least I can just restart it rather than needing to reboot after a swap outage. Colour depth also has an effect - changing from 8-bit to 32-bit on the X server seems to have made this worse (as you might expect). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: 4.0-Current, netscape halts system
On Mon, 25 Jan 1999, Matthew Dillon wrote: :One variable may be available memory. On my system, with default datasize :limit of 16M from login.conf, Netscape coredumps very frequently. With I've been using netscape on a 24bit color system for well over a year and have never had a serious memory leak problem or X session ( or machine ) crashing due to it. I don't leave the netscape window open all the time, though... I tend to exit out of it when I'm not using it. -Matt Matthew Dillon dil...@backplane.com Just to clarify: 1) I'm not sure I would necesarily accuse Netscape of having a leak: what with caching pages in RAM and the allocation policy of whatever malloc they use, maybe it really needs this much and would stabilise at some size of 100M+ - I just don't have the swap space to find out. 2) I have never seen a system crash as such. However, having the X server killed due to out-of-swap leaves the console fouled up and so could easily be mis-described as a crash. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Problem booting from aic7890/91 Ultra2 SCSI
On Sun, 17 Jan 1999, Christopher Knight wrote: At 08:11 PM 1/17/99 +0100, Gianmarco Giovannelli wrote: Please try to remove apm0 , if you have ... here it seems to solve the problem (after 15 reboot no problem...) I didn't have it compiled in. :( # # Laptop support (see LINT for more options) # #device apm0at isa? disable flags 0x31 # Advanced Power Management There seems to be some interaction with APM even without apm0 compiled in. I have a motherboard (AMI bios, about 1 year old) which works fine if APM is disabled in the BIOS setup, but with it enabled: - 2.2.x kernels seem to work fine. - 3.0R boot floppy boots and installs OK - 3.0R GENERIC kernel doesn't work - current kernels built in the past week or so don't work. All the above is exactly the same whether using old or new bootblocks. The combinations that don't work crash at a very early stage - you get the line printed by the loader showing the size of the kernel code/data/etc, then absolutely nothing more - no kernel startup, device probing or whatever. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Today's Make World
On Sat, 16 Jan 1999, Jordan K. Hubbard wrote: We're all seeing this error, not to worry. Happily, it's clearly Mark's baby since he both imported the new texinfo *and* does the perl5 stuff. :-) Backing out /usr/src/gnu/usr.bin/perl/libperl/config.SH* to 14jan allowed make world to complete for me. (revision 1.7 in the case of config.SH-elf.i386). To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
