Re: RT256x PCMCIA card under 7.0-BETA2
Okay, I'm back at work, and have cable internet here, so that I actually did some debugging and checking up on the problem just now. I think I narrowed the interrupt storm down to the end of scanning with the card. First of all a vmstat -i in three seconds interval while I was simply inserting the card into my PCMCIA slot (and the hotplug scripts did their magic): - Thu Nov 15 08:38:58 CET 2007 interrupt total rate irq1: atkbd01009 1 irq10: acpi0 229 0 irq14: ata0 8894 11 irq15: ata1 64 0 irq18: pcm0 5731 7 irq19: sis0+6542 8 irq20: ohci03789 4 irq21: ohci1 31 0 irq23: ehci0 3 0 cpu0: timer 1536343 1995 Total1562635 2029 - Thu Nov 15 08:39:01 CET 2007 - I inserted the card right about here interrupt total rate irq1: atkbd01010 1 irq10: acpi0 231 0 irq14: ata0 8915 11 irq15: ata1 64 0 irq17: cbb0 cbb1+ 11 0 irq18: pcm0 5731 7 irq19: sis0+6542 8 irq20: ohci03798 4 irq21: ohci1 31 0 irq23: ehci0 3 0 cpu0: timer 1542356 1995 Total1568692 2029 - Thu Nov 15 08:39:05 CET 2007 interrupt total rate irq1: atkbd01022 1 irq10: acpi0 231 0 irq14: ata0 8932 11 irq15: ata1 64 0 irq17: cbb0 cbb1+ 130576168 irq18: pcm0 5731 7 irq19: sis0+6545 8 irq20: ohci03908 5 irq21: ohci1 31 0 irq23: ehci0 3 0 cpu0: timer 1551118 1996 Total1708161 2198 - Thu Nov 15 08:39:08 CET 2007 interrupt total rate irq1: atkbd01030 1 irq10: acpi0 231 0 irq14: ata0 8932 11 irq15: ata1 64 0 irq17: cbb0 cbb1+ 351482450 irq18: pcm0 5731 7 irq19: sis0+6545 8 irq20: ohci03908 5 irq21: ohci1 31 0 irq23: ehci0 3 0 cpu0: timer 1557218 1996 Total1935175 2480 - Thu Nov 15 08:39:11 CET 2007 interrupt total rate irq1: atkbd01041 1 irq10: acpi0 233 0 irq14: ata0 8932 11 irq15: ata1 64 0 irq17: cbb0 cbb1+ 374391478 irq18: pcm0 5731 7 irq19: sis0+6547 8 irq20: ohci03952 5 irq21: ohci1 31 0 irq23: ehci0 3 0 cpu0: timer 1563474 1996 Total1964399 2508 - Thu Nov 15 08:39:15 CET 2007 interrupt total rate irq1: atkbd01050 1 irq10: acpi0 233 0 irq14: ata0 8932 11 irq15: ata1 64 0 irq17: cbb0 cbb1+ 607853773 irq18: pcm0 5731 7 irq19: sis0+6547 8 irq20: ohci03952 5 irq21: ohci1 31 0 irq23: ehci0 3 0 cpu0: timer 1569671 1997 Total2204067 2804 - Thu Nov 15 08:39:18 CET 2007 interrupt total rate irq1: atkbd01050 1 irq10: acpi0 233 0 irq14: ata0 8950 11 irq15: ata1 64 0 irq17: cbb0 cbb1+ 728523922 irq18: pcm0
Random data corruption with USB mass storage on 7.0-BETA2
Hey all! While trying to upload some music to my mobile phone, I stumbled across the following odd behaviour when uploading files to an SD-card (inserted into my Sony Ericsson M600i) which is connected via USB as a mass-storage device: - ... umass0: Sony Ericsson Mobile Communications M600i, class 2/0, rev 2.00/0.00, addr 2 on uhub0 ... da0 at umass-sim0 bus 0 target 0 lun 0 da0: M600i 1.0 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 59MB (121821 512 byte sectors: 64H 32S/T 59C) ... - The card is formatted as FAT (by the phone software), and I can mount it with a plain mount -t msdosfs /dev/da0 /mnt without any kind of problems, except that directories that should be there, at least as displayed by the File Manager on the phone, aren't present under the mount point. There is no output to dmesg on the mounting (besides the GEOM label for the stick being removed). When copying files to the device, the phone displays that a transfer is taking place, and after finishing the transfer, comparing files on the mountpoint to the source files shows them as being equal. When I then unmount the device (which also runs cleanly, without any further output to dmesg except the reappearance of the GEOM label) and remount it, the copied files appear under the mount-point, but comparing the files on the mount-point against the source files shows them as being different. The sizes and modification dates are equal, though, and most of a file is correct, but non-deterministically every 16k or similar a stream of random bytes appears. When I do the same transfer from a 6.2-STABLE (last csupped some two months ago), the directories the phone reports appear under the mount-point, and the same transfer works properly (i.e., uploading the file, unmounting, remounting and comparing show the files as being the same, and playing the file on the phone works, and doesn't contain corruption artefacts). The 6.2-STABLE shows similar information on the device in dmesg (esp. the H/S/C info). 6.2-STABLE is a plain GENERIC kernel, with atapicam loaded (and some other device drivers for sound and Bluetooth), 7.0-BETA2 is a slightly adapted GENERIC (with SCHED_4BSD replaced with SCHED_ULE and SMP support removed) also with atapicam loaded (and some other device drivers for sound and bluetooth). I'll try to do some digging into the changes made to msdosfs between 6.2-STABLE and 7.0-BETA2 some time later on, but if anybody else is seeing this behaviour too or wants me to produce more debugging info on this (esp. some msdosfs debugging infos), feel free to send me a mail, and I'll try to get this done some time during the day. -- Heiko Wundram Product Application Development ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-update 6.2-R - 6.3-B1 rollback failed
Colin Percival wrote: Jan Henrik Sylvester wrote: I tried to rollback the freebsd-update 6.2-R - 6.3-B1. To confirm that I understand what you're saying here: You upgraded from FreeBSD 6.2-RELEASE to 6.3-BETA1, then you ran freebsd-update rollback to move back to FreeBSD 6.2-RELEASE, right? 'sh freebsd-update.sh -f freebsd-update.conf rollback' was the command, but that is correct. Nope, not your fault -- I screwed up the rollback code. I did not think I was the first to do this rollback -- good that I tested it. Now, how do I get this machine running again? I believe that your system is now 6.3-BETA1 with a few shared libraries from 6.2-RELEASE mixed in. If you can get a copy of /lib/*.so.* and /usr/lib/*.so.* from a 6.3-BETA1 system and install those into place (in fact, probably all you need is /lib/libc.so.6) your system should be ok. Let me know if you need any help with this. I guess I can download a 6.3-BETA1 cd and copy the files over from there. If you have a better way, please, let me know. Getting the system back to 6.2-RELEASE might be more difficult, now that the FreeBSD Update code thinks that it has rolled back its updates, but I might be able to find a way to do that for you -- is it a disaster if this system ends up stuck at 6.3-BETA1? Not to be able to go back to 6.2-RELEASE is ok. If updating to 6.3-BETA2 (and eventually perhaps 7.0) is not possible because of the mixed system, it will limit my testing and I will have to reinstall at some point, which would not be a disaster, either. (Sometimes I do testing that feels rather save on my main working machine -- I am glad I was not so insane this time.) Is there any cleanup to do besides replacing the libs (such as removing temporary freebsd-update directories)? Since your blog seems not to tell and there is no other documentation: Is freebsd-update -r supposed to work if not all files are from GENERIC/SMP? Does it skip files or overwrite them with GENERIC versions? (For security updates, the former might be desirable, but for updates between releases, only the latter would make sense to me.) Thanks, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Filesystems in 7.0 reliability
Norberto Meijome wrote: Any issues with ZFS on a single HD ? I think it's currently not recommended to use swapfiles on ZFS. Other than that, I'm not aware of any issues. any point doing that? Sure! Getting rid of static partition sizes, checksums for everything (preventing silent corruption), the ability to store multiple copies of important files, compression, and lots of other useful things. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ZFS from FreeBSD - Indiana - FreeBSD - some problem
It's good to know that ZFS is compatible between the two operating systems :) With some issues. Some time ago I made an experiment to install on the same ZFS both FreeBSD and Solaris, and, if you set up FreeBSD with ZFS root, you will be unable to boot it after using ZFS volume in Solaris and vice versa, if you set up Solaris with ZFS root, you will be unable to boot it after using volume in FreeBSD. Unexported ZFS pool contains direct references to block devices it consist of. As such, when FreeBSD tries to auto-import ZFS pool with /dev/rdsk/c1t0d0s7 as a storage device, it becomes crazy. :) Solaris do the same thing, it knows nothing about ad6s3 :) 'zpool status' will show you that entire pool has destroyed because of no storage devices available. Sure, zpool export immediately before reboot will do the thing right way, but how you will automatically export ZFS pool with root file system on it?-) -- Yours Andrew Kolchoogin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 or FreeBSD 7.0
Looking at the Overview of FreeBSD-7.0, I would use it as my production, as long as my fail over servers are standby (e.g. postgres with PITR, MySQL-5.0 with replication). But if you are using 1 server for production use FreeBSD-6.3-R. My 2 cents for FreeBSD-7.0-R. br, On Nov 14, 2007 7:23 PM, Marko Lerota [EMAIL PROTECTED] wrote: I see that 6.3 and 7.0 is comming. Now I'm using 6.2-RELEASE for my servers. To what should I upgrade? Which of them will be stable or production release? -- One cannot sell the earth upon which the people walk Tacunka Witco ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Jimmy B. Lim j i m m y b l i m @ g m a i l . c o m ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Float problen running i386 inary on amd64
On Fri, Nov 02, 2007 at 10:04:48PM +, Pete French wrote:
int
main(int argc, char *argv[])
{
if(atof(3.2) =3D=3D atof(3.200))
puts(They are equal);
else
puts(They are NOT equal!);
return 0;
}
Since the program as defined above does not include any prototype for
atof(), its return value is assumed to be int. The i386 code for the
comparison is therefore:
Sorry, I didn't bother sticking the include lines in when I sent it
to the mailing list as I assumed it would be ovious that you need
to include the prototypes! In the actual tests I did I included stdio.h
and stdlib.h, so the compiler did know the return type. The result is the
same, different behaviour when running the i386 binary on amd64.
Note that this is comparing the %eax returned by each atof(). Since
atof() actually returns a double in %st(0) and %eax is a scratch
register, the results are completely undefined.
I just tried this with the actual code I used for the test (i.e. with the
header files included) and I get something a lot longer than the
assembler you posted. I don't really understand what it is doing as I don't
read 386 assembler, and it's not exactly self explanatory. But the error
is still there.
Interestingly, if you recode like this:
double x = atof(3.2);
double y = atof(3.200);
if(x == y)
puts(They are equal);
else
puts(They are NOT equal!);
Then the problem goes away! Glancing at the assembly code they both appear to
be doing the same thing as regards the comparison.
Unfortunately, I can't explain why an i386 would be different to an amd64
in i386 mode.
me neither :-(
So, this is a bug, yes ? but it is a bug in FreeBSD or not ?
-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random data corruption with USB mass storage on 7.0-BETA2
On Thu, Nov 15, 2007 at 09:52:34AM +0100, Heiko Wundram (Beenic) wrote: Hey all! While trying to upload some music to my mobile phone, I stumbled across the following odd behaviour when uploading files to an SD-card (inserted into my Sony Ericsson M600i) which is connected via USB as a mass-storage device: - ... umass0: Sony Ericsson Mobile Communications M600i, class 2/0, rev 2.00/0.00, addr 2 on uhub0 ... da0 at umass-sim0 bus 0 target 0 lun 0 da0: M600i 1.0 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 59MB (121821 512 byte sectors: 64H 32S/T 59C) ... - The card is formatted as FAT (by the phone software), and I can mount it with a plain mount -t msdosfs /dev/da0 /mnt without any kind of problems, except that directories that should be there, at least as displayed by the File Manager on the phone, aren't present under the mount point. There is no output to dmesg on the mounting (besides the GEOM label for the stick being removed). When copying files to the device, the phone displays that a transfer is taking place, and after finishing the transfer, comparing files on the mountpoint to the source files shows them as being equal. When I then unmount the device (which also runs cleanly, without any further output to dmesg except the reappearance of the GEOM label) and remount it, the copied files appear under the mount-point, but comparing the files on the mount-point against the source files shows them as being different. The sizes and modification dates are equal, though, and most of a file is correct, but non-deterministically every 16k or similar a stream of random bytes appears. When I do the same transfer from a 6.2-STABLE (last csupped some two months ago), the directories the phone reports appear under the mount-point, and the same transfer works properly (i.e., uploading the file, unmounting, remounting and comparing show the files as being the same, and playing the file on the phone works, and doesn't contain corruption artefacts). The 6.2-STABLE shows similar information on the device in dmesg (esp. the H/S/C info). 6.2-STABLE is a plain GENERIC kernel, with atapicam loaded (and some other device drivers for sound and Bluetooth), 7.0-BETA2 is a slightly adapted GENERIC (with SCHED_4BSD replaced with SCHED_ULE and SMP support removed) also with atapicam loaded (and some other device drivers for sound and bluetooth). I'll try to do some digging into the changes made to msdosfs between 6.2-STABLE and 7.0-BETA2 some time later on, but if anybody else is seeing this behaviour too or wants me to produce more debugging info on this (esp. some msdosfs debugging infos), feel free to send me a mail, and I'll try to get this done some time during the day. I'm not sure that it is msdosfs' fault. Last night I also corrupted my FAT based USB memory stick. But I used mtools and did not mount it. That was on 8-current though. I have not looked into it because there are other higher priority stuff also not working. :-/ John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot recent -stable with MSI/MSIX enabled
On Saturday 13 October 2007 11:59:40 am Alson van der Meulen wrote: * Jack Vogel [EMAIL PROTECTED] [2007-10-13 05:19]: A suggestion, take the relevant files from my em driver and put them back into the kernel tree that was working on 10/1, it should be compatible. Then see if it breaks that kernel. Or if you'd prefer I can just email the tar ball for the Intel version of 6.6.6, you can disable the in-kernel em driver, and build the other and use that with the 10/1 kernel. Then I removed sys/dev/em and copied it from the 10/12 sources. I also copied sys/conf/files, sys/conf/kern.pre.mk and sys/modules/em/Makelfile from the 10/12 sources; this should be all of the 6.6.6 merge. Compiled with same config, booted with MSI/MSIX enabled. Surprisingly, this kernel behaved different than the 10/10 and 10/12 kernels. It booted OK without any major errors, only a few watchdog timeouts and link down/ups on em0. It was very slow though. Top showed 60% interrupt. vmstat -i: interrupt total rate irq4: sio0 3563 8 irq6: fdc0 1 0 irq14: ata0 58 0 irq16: fxp0 32076072 79593 irq21: atapci1+24300 60 cpu0: timer 793477 1968 Total 32897471 81631 There wasn't much traffic on fxp0 (only ssh, ping and ntp). According to dmesg, em0 used the same IRQ as fxp0, except it should be using MSI: em0: Intel(R) PRO/1000 Network Connection Version - 6.6.6 port 0xdf00-0xdf1f mem 0xfdde-0xfddf,0xfddc-0xfddd irq 16 at device 0.0 on pci5 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfdde em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 56 em0: using IRQ 256 for MSI em0: bpf attached em0: Ethernet address: 00:15:17:19:59:e4 em0: [FAST] It appears that em0 still generates interrupts on irq16, even though it should be using MSI. This was due to a bug with rman_set_rid() not getting used in 6-stable that broke the most recent MSI MFC. The rman thing was fixed on 10/3, so MSI is not expected to work on 6-stable kernels between 8/15 and 10/3. Are you still having problems with em + MSI? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel Matrix RAID (ICH8R) rebuild?
On Monday 21 May 2007 09:49:19 am Krassimir Slavchev wrote: Bob Bishop wrote: On 21 May 2007, at 12:52, Krassimir Slavchev wrote: Bob Bishop wrote: Hi, On 21 May 2007, at 10:07, Krassimir Slavchev wrote: Hello, I have problems rebuilding RAID1 array. The bios shows status 'Rebuild' and 'Volumes with Rebuild status will be rebuilt within the operating system'. When I try to do 'atacontrol rebuild ar0': atacontrol: ioctl(IOCATARAIDREBUILD): Device not configured From the output below, assuming the system is running OK, the RAID doesn't need rebuilding. The BIOS is just confused about the state of the array, it will probably still boot from it OK. Yes, it boots OK but the RAID need rebuilding. This status is result of disconnecting the second disk, booting, create some files and then reconnect the second disk. [etc] OK. You need to follow the steps in http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/raid.html section 18.4.3. Be careful to detach/reattach the right disk :-) When the rebuild has finished you may find that the BIOS doesn't realize the array has been rebuilt, but that may not matter (much). After rebuilding the bios shows 'Normal' status. It seems that the ata-raid driver can't detect when the array need rebuilding. Thanks for your help The ata-raid driver does not automatically start a rebuild, you have to kick if off by hand. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 or FreeBSD 7.0
Jimmy Lim [EMAIL PROTECTED] writes: But if you are using 1 server for production use FreeBSD-6.3-R. My 2 cents for FreeBSD-7.0-R. For my personal servers I'll jump to 7.0-R, but for some customers, will wait for 7.1-R. TNX -- One cannot sell the earth upon which the people walk Tacunka Witco ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Filesystem corruption and bad perfomance with SRCS16 and PAE ( raid 5 2TB)
On Wednesday 07 February 2007 04:58:17 am Daniel O'Connor wrote: On Wednesday 07 February 2007 19:23, Artem Kuchin wrote: FreeBSD/amd64 is a very young platform on FreeBSD. While the core FreeBSD kernel and base system components are generally fairly robust, there are likely to still be rough edges, particularly with third party packages. scares me. Do you really think it is better than PAE? PAE is quite young as well, I think it was committed to the tree around March 2003. The earliest AMD64 commit I could find was May 2003 although repo copying makes it confusing.. I think you'll find the list of drivers incompatible with PAE to be much longer with amd64. Err, amd64 and PAE are the same problem for drivers (dealing with 64-bit physical addresses for DMA which can require bounce buffering if your hardware only supports 32-bit physical addresses). The fix is to use the bus_dma abstraction in the driver instead of directly using vtophys() and a driver needs that fix for both PAE and amd64. amr(4) should work fine with both PAE and amd64 with 4GB of RAM. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[FreeBSD6.2 panic] vm_fault: fault on nofault entry
Hi,
my server paniced with the string
panic: vm_fault: fault on nofault entry, addr: dadb1000.
I've attached the backtrace. The backtrace looks similar to the backtrace in
kern/115374.
Is this a known problem? Is there a patch available?
I can provide the kernel config and dmesg output, if needed. And, if necessary,
I can enter additional commands to the debuger, but I'm not able to reproduce
the panic.
bye,
Hilko
PS: please keep me Cc'ed, cause I'm not subscribed to this list.
Script started on Thu Nov 15 16:22:12 2007
kgdb: kvm_nlist(_stopped_cpus):
kgdb: kvm_nlist(_stoppcbs):
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
panic: vm_fault: fault on nofault entry, addr: dadb1000
Uptime: 2d17h37m42s
Dumping 511 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 511MB (130800 pages) 495 479 463 447 431 415 399 383 367 351 335 319
303 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bacj ktrace
#0 doadump () at pcpu.h:165
#1 0xc051f324 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc051f67d in panic (fmt=0xc06f58a7 vm_fault: fault on nofault entry,
addr: %lx) at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc06584fc in vm_fault (map=0xc104b000, vaddr=3671789568, fault_type=2
'\002', fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:279
#4 0xc06b0dda in trap_pfault (frame=0xdadbfa90, usermode=0, eva=3671792077) at
/usr/src/sys/i386/i386/trap.c:734
#5 0xc06b09ad in trap (frame=
{tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = -1011600872, tf_esi =
-1010749952, tf_ebp = -623117576, tf_isp = -623117636, tf_ebx = 4, tf_edx =
-1007446528, tf_ecx = 4, tf_eax = 41, tf_trapno = 12, tf_err = 2, tf_eip =
-1068566704, tf_cs = 32, tf_eflags = 66050, tf_esp = -1068551783, tf_ss =
-1010749952}) at /usr/src/sys/i386/i386/trap.c:435
#6 0xc069ceca in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7 0xc04ef750 in swapcontext ()
#8 0xc04f35d6 in falloc (td=0xc3f39600, resultfp=0xdadbfb58,
resultfd=0xdadbfb5c) at /usr/src/sys/kern/kern_descrip.c:1372
#9 0xc058ed0a in kern_open (td=0xc3f39600, path=0x29 Address 0x29 out of
bounds, pathseg=41, flags=1, mode=0)
at /usr/src/sys/kern/vfs_syscalls.c:1001
#10 0xc058ec86 in open (td=0x29, uap=0xdadbfd04) at
/usr/src/sys/kern/vfs_syscalls.c:973
#11 0xc06b1542 in syscall (frame=
{tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 138039296, tf_esi = 0,
tf_ebp = -1077955400, tf_isp = -623116956, tf_ebx = 677954740, tf_edx = 0,
tf_ecx = 0, tf_eax = 5, tf_trapno = 0, tf_err = 2, tf_eip = 678754903, tf_cs =
51, tf_eflags = 582, tf_esp = -1077955428, tf_ss = 59}) at
/usr/src/sys/i386/i386/trap.c:983
#12 0xc069cf1f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#13 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) quit
Script done on Thu Nov 15 16:22:20 2007
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Filesystem corruption and bad perfomance with SRCS16 and PAE ( raid 5 2TB)
John Baldwin wrote: On Wednesday 07 February 2007 04:58:17 am Daniel O'Connor wrote: On Wednesday 07 February 2007 19:23, Artem Kuchin wrote: FreeBSD/amd64 is a very young platform on FreeBSD. While the core FreeBSD kernel and base system components are generally fairly robust, there are likely to still be rough edges, particularly with third party packages. scares me. Do you really think it is better than PAE? PAE is quite young as well, I think it was committed to the tree around March 2003. The earliest AMD64 commit I could find was May 2003 although repo copying makes it confusing.. I think you'll find the list of drivers incompatible with PAE to be much longer with amd64. Err, amd64 and PAE are the same problem for drivers (dealing with 64-bit physical addresses for DMA which can require bounce buffering if your hardware only supports 32-bit physical addresses). The fix is to use the bus_dma abstraction in the driver instead of directly using vtophys() and a driver needs that fix for both PAE and amd64. amr(4) should work fine with both PAE and amd64 with 4GB of RAM. Actually, they are different problems. There are all sorts of fun ways for a driver to be 64-bit unclean in ways that will make it work with amd64 but not with PAE. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Unable to boot recent -stable with MSI/MSIX enabled
On Nov 15, 2007 7:17 AM, John Baldwin [EMAIL PROTECTED] wrote: On Saturday 13 October 2007 11:59:40 am Alson van der Meulen wrote: * Jack Vogel [EMAIL PROTECTED] [2007-10-13 05:19]: A suggestion, take the relevant files from my em driver and put them back into the kernel tree that was working on 10/1, it should be compatible. Then see if it breaks that kernel. Or if you'd prefer I can just email the tar ball for the Intel version of 6.6.6, you can disable the in-kernel em driver, and build the other and use that with the 10/1 kernel. Then I removed sys/dev/em and copied it from the 10/12 sources. I also copied sys/conf/files, sys/conf/kern.pre.mk and sys/modules/em/Makelfile from the 10/12 sources; this should be all of the 6.6.6 merge. Compiled with same config, booted with MSI/MSIX enabled. Surprisingly, this kernel behaved different than the 10/10 and 10/12 kernels. It booted OK without any major errors, only a few watchdog timeouts and link down/ups on em0. It was very slow though. Top showed 60% interrupt. vmstat -i: interrupt total rate irq4: sio0 3563 8 irq6: fdc0 1 0 irq14: ata0 58 0 irq16: fxp0 32076072 79593 irq21: atapci1+24300 60 cpu0: timer 793477 1968 Total 32897471 81631 There wasn't much traffic on fxp0 (only ssh, ping and ntp). According to dmesg, em0 used the same IRQ as fxp0, except it should be using MSI: em0: Intel(R) PRO/1000 Network Connection Version - 6.6.6 port 0xdf00-0xdf1f mem 0xfdde-0xfddf,0xfddc-0xfddd irq 16 at device 0.0 on pci5 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfdde em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to vector 56 em0: using IRQ 256 for MSI em0: bpf attached em0: Ethernet address: 00:15:17:19:59:e4 em0: [FAST] It appears that em0 still generates interrupts on irq16, even though it should be using MSI. This was due to a bug with rman_set_rid() not getting used in 6-stable that broke the most recent MSI MFC. The rman thing was fixed on 10/3, so MSI is not expected to work on 6-stable kernels between 8/15 and 10/3. Are you still having problems with em + MSI? I got diverted with this S7000 bringup and haven't looked since that last point in the thread. I am working in parallel on splitting the E1000 driver and may be able to check this in a bit. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Marvell Yukon msk/msi problem
On Thursday 12 April 2007 08:36:02 am Danny Braniss wrote: hi, The if_msk works fine under -current, but under -stable it does not use the MSI capability, and since it's a shared IRQ, it works less than optimal under heavy cpu load. Pyun YongHyeon suggested to search for help here :-) from the if_msk: ... pci_alloc_msi(dev, msic) == 0) ... under -current pci_alloc_msi(...) returns 0, but under -stable this fails. MSI is not enabled by default in 6-stable. You need to set 'hw.pci.enable_msi=1' in the loader to enable it. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: interrupt from missing bus(HP xw8400 WS)
On Thursday 08 February 2007 05:24:08 am KAWAGUTI Ginga wrote: Hi. I'm using [6.2-STABLE of Tue Feb 6 16:17:03 JST 2007], and HP xw8400 PC with 4GB memory, 2.0GHz Xeon x1. Other configuration is SAS(on-board), SCSI(see below). When FreeBSD-6-stable boots with this PC, it always panics at very first stage of booting just after loader. * Only way I can boot with this PC is to select safe-mode at loader selection(no SMP, etc...). * Disabling ACPI(as below), is not sufficient. loader unset acpi_load loader set hint.acpi.0.disabled=1 * GENERIC kernel also behaves the same. * Same thing happens with 6.2-R or before. --- boot message going panic: .. FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic2: Assuming intbase of 48 panic: interrupt from missing bus cpuid - 0 Uptime: 1s Automatic reboot in 15 seconds You have a busted mp table. The mp table isn't used if ACPI is present, so perhaps ACPI is disabled in the BIOS? -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
Hello, freebsd-stable. Upgrading my netwrok from 100Mbit to 1Gbit. I've replaced one of two fxp's with em (desktop varinat), and rebuild system. Right after booting TONS of messages about interrupt storm (without device name). irq11 is occuped by em0. uname -a FreeBSD xxx.xxx.xxx 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Nov 15 19:19:26 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY i386 Here is dmesg.boot: Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-PRERELEASE #0: Thu Nov 15 19:19:26 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY Copyright (c) 1992-2007 The FreeBSD Project.Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (551.25-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 671072256 (639 MB) avail memory = 647380992 (617 MB) ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: ASUS P3B_F on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe700-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, USB at device 4.2 (no driver attached) intpm0: Intel 82371AB Power management controller port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: Intel PIIX4 SMBUS Interface on intpm0 smbus1: System Management Bus on intsmb0 smb0: SMBus generic I/O on smbus1 intpm0: PM I/O mapped e400 ath0: Atheros 5212 mem 0xe380-0xe380 irq 12 at device 10.0 on pci0 ath0: Ethernet address: 00:15:e9:40:61:59 ath0: mac 7.9 phy 4.5 radio 5.6 fxp0: Intel 82558 Pro/100 Ethernet port 0xb000-0xb01f mem 0xe500-0xe5000fff,0xe300-0xe30f irq 10 at device 11.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:50:8b:5d:ac:cb em0: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0xa800-0xa83f mem 0xe280-0xe281,0xe200-0xe201 irq 11 at device 12.0 on pci0 em0: Ethernet address: 00:07:e9:09:ed:f3 pci0: simple comms at device 13.0 (no driver attached) ppc0: ECP parallel printer port port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc87ff,0xcc000-0xccfff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 551253671 Hz quality 800 Timecounters tick every 1.000 msec interrupt storm detected on irq11:; throttling interrupt source ad0: 76351MB SAMSUNG SP0802N TK200-04 at ata0-master UDMA33 acd0: CDROM CD-532E-B/3.0B at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source -- // Black Lion AKA Lev
Re: Float problen running i386 inary on amd64
I've Cc'd bde@ because this relates to the FPU initialisation - which
he is the expert on.
On Thu, Nov 15, 2007 at 12:54:29PM +, Pete French wrote:
On Fri, Nov 02, 2007 at 10:04:48PM +, Pete French wrote:
int
main(int argc, char *argv[])
{
if(atof(3.2) == atof(3.200))
puts(They are equal);
else
puts(They are NOT equal!);
return 0;
}
Since the program as defined above does not include any prototype for
atof(), its return value is assumed to be int. The i386 code for the
comparison is therefore:
Sorry, I didn't bother sticking the include lines in when I sent it
to the mailing list as I assumed it would be ovious that you need
to include the prototypes!
OK, sorry for the confusion.
Interestingly, if you recode like this:
double x = atof(3.2);
double y = atof(3.200);
if(x == y)
puts(They are equal);
else
puts(They are NOT equal!);
Then the problem goes away! Glancing at the assembly code they both appear to
be doing the same thing as regards the comparison.
The underlying problem is that the amd64 FPU is initialised to 64-bit
precision mode, whilst the i386 FPU is initialised to 53-bit precision
mode (__INITIAL_FPUCW__ in amd64/include/fpu.h vs __INITIAL_NPXCW__ in
i386/include/npx.h). It looks like the FPU is initialised during the
machine-dependent CPU initialisation and then inherited by subsequent
processes as they are fork()d. The fix is probably to explicitly
initialise the FPU for legacy mode processes on the amd64.
A work-around would be to call fpsetprec(FP_PD) (see machine/ieeefp.h)
at the start of main().
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
pgpg4imMtCLmB.pgp
Description: PGP signature
New Device IDs
I was curious, is there any organized method to funnel new IDs into the code or is it just willy nilly as a driver owner notices it? I will be having some patches to add IDs from this bringup I've been working on and wondered if there was a 'canonical' way to make this stuff happen? Cheers, Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: New Device IDs
Jack Vogel wrote: I was curious, is there any organized method to funnel new IDs into the code or is it just willy nilly as a driver owner notices it? I will be having some patches to add IDs from this bringup I've been working on and wondered if there was a 'canonical' way to make this stuff happen? Willy Nilly. Commit away! Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
vmstat -i Disconnect the cable from it when you boot, also pciconf -l to see what type adapter it is. This is storming before you assign it an address? On Nov 15, 2007 11:18 AM, Lev Serebryakov [EMAIL PROTECTED] wrote: Hello, freebsd-stable. Upgrading my netwrok from 100Mbit to 1Gbit. I've replaced one of two fxp's with em (desktop varinat), and rebuild system. Right after booting TONS of messages about interrupt storm (without device name). irq11 is occuped by em0. uname -a FreeBSD xxx.xxx.xxx 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #0: Thu Nov 15 19:19:26 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY i386 Here is dmesg.boot: Copyright (c) 1992-2007 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-PRERELEASE #0: Thu Nov 15 19:19:26 MSK 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY Copyright (c) 1992-2007 The FreeBSD Project.Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (551.25-MHz 686-class CPU) Origin = GenuineIntel Id = 0x673 Stepping = 3 Features=0x387f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,PN,MMX,FXSR,SSE real memory = 671072256 (639 MB) avail memory = 647380992 (617 MB) ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: ASUS P3B_F on motherboard acpi0: Power Button (fixed) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82443BX (440 BX) host to PCI bridge mem 0xe700-0xe7ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 UDMA33 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xb800-0xb80f at device 4.1 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, USB at device 4.2 (no driver attached) intpm0: Intel 82371AB Power management controller port 0xe800-0xe80f irq 9 at device 4.3 on pci0 intpm0: I/O mapped e800 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: Intel PIIX4 SMBUS Interface on intpm0 smbus1: System Management Bus on intsmb0 smb0: SMBus generic I/O on smbus1 intpm0: PM I/O mapped e400 ath0: Atheros 5212 mem 0xe380-0xe380 irq 12 at device 10.0 on pci0 ath0: Ethernet address: 00:15:e9:40:61:59 ath0: mac 7.9 phy 4.5 radio 5.6 fxp0: Intel 82558 Pro/100 Ethernet port 0xb000-0xb01f mem 0xe500-0xe5000fff,0xe300-0xe30f irq 10 at device 11.0 on pci0 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:50:8b:5d:ac:cb em0: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0xa800-0xa83f mem 0xe280-0xe281,0xe200-0xe201 irq 11 at device 12.0 on pci0 em0: Ethernet address: 00:07:e9:09:ed:f3 pci0: simple comms at device 13.0 (no driver attached) ppc0: ECP parallel printer port port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: 16550A-compatible COM port port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: ISA Option ROMs at iomem 0xc-0xc7fff,0xc8000-0xc87ff,0xcc000-0xccfff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio2 at port 0x3e8-0x3ef irq 5 on isa0 sio2: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter TSC frequency 551253671 Hz quality 800 Timecounters tick every 1.000 msec interrupt storm detected on irq11:; throttling interrupt source ad0: 76351MB SAMSUNG SP0802N TK200-04 at ata0-master UDMA33 acd0: CDROM CD-532E-B/3.0B at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s1a interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source interrupt storm detected on irq11:; throttling interrupt source
Re[2]: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
Hello, Jack. You wrote 15 ?? 2007 ?., 22:46:59: (after loading drivers for my X100P Zaptel voice card, but it doesn't change anything). vmstat -i interrupt total rate irq0: clk2956764999 irq6: wcfxo0 85000 28 irq7: ppc0 1 0 irq8: rtc 378406127 irq10: fxp037732 12 irq11: em0 2957170999 irq12: ath064647 21 irq14: ata012713 4 irq15: ata1 18 0 Total6492451 2194 Disconnect the cable from it when you boot, also pciconf -l [EMAIL PROTECTED]:12:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 Cable was disconnected... to see what type adapter it is. This is storming before you assign it an address? It seems so, because the first message in `dmesg' is BEFORE ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled and RIGHT AFTER Trying to mount root from ufs:/dev/ad0s1a. BTW, card WORKS in such conditions: I can connect cable, and ping this interface (this is head-less computer, I access it through wi-fi from my notebook while wired network is stopped). -- // Black Lion AKA Lev Serebryakov [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Random data corruption with USB mass storage on 7.0-BETA2
You need to check is it FAT12 or FAT16 on a card. AFAIR fdisk can show this info. Had the same problem with SE 64Mb card in K750i. It turned out that SE creates FAT12 on a 32+Mb disk, which is not supposed to be an option. Some time ago this was discussed, but I was unable to provide a dump from such card (have no such card anymore). PS. To just make it work - just re-format it and restore folders structure. But please, create a filesystem dump first, to let developers decide is it a fault of SE phone or MSDOSFS code. PPS. http://docs.FreeBSD.org/cgi/mid.cgi?b84edfa10707011305g4cffb298q70c3507f75121799 2007/11/15, Heiko Wundram (Beenic) [EMAIL PROTECTED]: Hey all! While trying to upload some music to my mobile phone, I stumbled across the following odd behaviour when uploading files to an SD-card (inserted into my Sony Ericsson M600i) which is connected via USB as a mass-storage device: - ... umass0: Sony Ericsson Mobile Communications M600i, class 2/0, rev 2.00/0.00, addr 2 on uhub0 ... da0 at umass-sim0 bus 0 target 0 lun 0 da0: M600i 1.0 Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 59MB (121821 512 byte sectors: 64H 32S/T 59C) ... - The card is formatted as FAT (by the phone software), and I can mount it with a plain mount -t msdosfs /dev/da0 /mnt without any kind of problems, except that directories that should be there, at least as displayed by the File Manager on the phone, aren't present under the mount point. There is no output to dmesg on the mounting (besides the GEOM label for the stick being removed). When copying files to the device, the phone displays that a transfer is taking place, and after finishing the transfer, comparing files on the mountpoint to the source files shows them as being equal. When I then unmount the device (which also runs cleanly, without any further output to dmesg except the reappearance of the GEOM label) and remount it, the copied files appear under the mount-point, but comparing the files on the mount-point against the source files shows them as being different. The sizes and modification dates are equal, though, and most of a file is correct, but non-deterministically every 16k or similar a stream of random bytes appears. When I do the same transfer from a 6.2-STABLE (last csupped some two months ago), the directories the phone reports appear under the mount-point, and the same transfer works properly (i.e., uploading the file, unmounting, remounting and comparing show the files as being the same, and playing the file on the phone works, and doesn't contain corruption artefacts). The 6.2-STABLE shows similar information on the device in dmesg (esp. the H/S/C info). 6.2-STABLE is a plain GENERIC kernel, with atapicam loaded (and some other device drivers for sound and Bluetooth), 7.0-BETA2 is a slightly adapted GENERIC (with SCHED_4BSD replaced with SCHED_ULE and SMP support removed) also with atapicam loaded (and some other device drivers for sound and bluetooth). I'll try to do some digging into the changes made to msdosfs between 6.2-STABLE and 7.0-BETA2 some time later on, but if anybody else is seeing this behaviour too or wants me to produce more debugging info on this (esp. some msdosfs debugging infos), feel free to send me a mail, and I'll try to get this done some time during the day. -- Heiko Wundram Product Application Development ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Dennis Melentyev ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[4]: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
Hello, Jack. You wrote 15 ?? 2007 ?., 23:03:46: sysctl hw.intr_storm_threshold If I set this onw to 1, em0 generate 1001-1002 irq per second (accroding to vmstat -i) without any storm messages :) In this old of an adapter though seems more likely something is wrong. Yep... 1002 ips without traffic... It is too much, IMHO :) Let me see if our test group can dig up this adapter and try it. It was sold as: Intel PWLA 8390-MT Pro/ 1000MT (chip 82540EM) OEM -- // Black Lion AKA Lev Serebryakov [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[2]: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
On Nov 15, 2007 11:52 AM, Lev Serebryakov [EMAIL PROTECTED] wrote: Hello, Jack. You wrote 15 ?? 2007 ?., 22:46:59: (after loading drivers for my X100P Zaptel voice card, but it doesn't change anything). vmstat -i interrupt total rate irq0: clk2956764999 irq6: wcfxo0 85000 28 irq7: ppc0 1 0 irq8: rtc 378406127 irq10: fxp037732 12 irq11: em0 2957170999 irq12: ath064647 21 irq14: ata012713 4 irq15: ata1 18 0 Total6492451 2194 Disconnect the cable from it when you boot, also pciconf -l [EMAIL PROTECTED]:12:0: class=0x02 card=0x002e8086 chip=0x100e8086 rev=0x02 hdr=0x00 Cable was disconnected... to see what type adapter it is. This is storming before you assign it an address? It seems so, because the first message in `dmesg' is BEFORE ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled and RIGHT AFTER Trying to mount root from ufs:/dev/ad0s1a. BTW, card WORKS in such conditions: I can connect cable, and ping this interface (this is head-less computer, I access it through wi-fi from my notebook while wired network is stopped). Yes, sometimes the rate of interrupts just is higher than the system sets the storm threshhold, for 10G we need to up the system threshhold. sysctl hw.intr_storm_threshold In this old of an adapter though seems more likely something is wrong. Let me see if our test group can dig up this adapter and try it. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Fwd: [Re: openpty() and jail in RELENG_7]
- Forwarded message from Dan Epure [EMAIL PROTECTED] - Date: Thu, 15 Nov 2007 19:11:43 +0200 From: Dan Epure [EMAIL PROTECTED] To: John Baldwin [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: openpty() and jail in RELENG_7 The /etc/defaults/devfs.rules version is: # $FreeBSD: src/etc/defaults/devfs.rules,v 1.4.2.1 2007/11/11 22:52:31 csjp Exp $ This solved my problem. But other issues came out. 1. The following patch would help the stop/start of the jail (now, if you stop and start a jail /dev/pts and /dev/pty would not show again): === cut here === *** /usr/src/etc/defaults/devfs.rules Mon Nov 12 09:56:30 2007 --- /etc/defaults/devfs.rules Thu Nov 15 18:20:35 2007 *** *** 54,56 --- 54,58 add path 'ttyS*' unhide + add path 'pts' unhide add path 'pts/*' unhide + add path 'pty' unhide add path 'pty/*' unhide === and here === 2. I noticed a strange behavior. === cut here === # ls -la /dev/pt[sy]/ /dev/pts/: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:46 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:42 .. crw-rw-rw- 1 root wheel0, 95 Nov 15 18:48 0 /dev/pty/: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:46 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:42 .. crw-rw-rw- 1 root wheel0, 93 Nov 15 18:48 0 # ls -la /dev/ptmx crw-rw-rw- 1 root wheel0, 99 Nov 15 18:41 /dev/ptmx # ls -la /dev/pt[sy] /dev/pts: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:45 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:41 .. crw--w 1 gepu tty 0, 95 Nov 15 19:06 0 /dev/pty: total 1 dr-xr-xr-x 2 root wheel 512 Nov 15 18:45 . dr-xr-xr-x 6 root wheel 512 Nov 15 18:41 .. crw-rw-rw- 1 root wheel0, 93 Nov 15 19:06 0 crw-rw-rw- 1 root wheel0, 99 Nov 15 18:41 1 crw-rw-rw- 1 root wheel0, 100 Nov 15 18:41 2 === and here === for every ls -la /dev/ptmx I get another two entries in /dev/pty and no aditional entry in /dev/pts. I can repeat this until I reach kern.pts.max in /dev/pty. At this moment there is not available pty. Regards, Gepu On Thu, Nov 15, 2007 at 08:56:34AM -0500, John Baldwin wrote: On Sunday 11 November 2007 06:24:56 am Dan Epure wrote: Maybe I have better luck here: Do you have the recent fix to unhide /dev/pts devices in the default jail rules for devfs? -- John Baldwin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] - End forwarded message - ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[4]: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
On Nov 15, 2007 12:45 PM, Lev Serebryakov [EMAIL PROTECTED] wrote: Hello, Jack. You wrote 15 ?? 2007 ?., 23:03:46: sysctl hw.intr_storm_threshold If I set this onw to 1, em0 generate 1001-1002 irq per second (accroding to vmstat -i) without any storm messages :) In this old of an adapter though seems more likely something is wrong. Yep... 1002 ips without traffic... It is too much, IMHO :) Let me see if our test group can dig up this adapter and try it. It was sold as: Intel PWLA 8390-MT Pro/ 1000MT (chip 82540EM) OEM My test engineer has an adapter and is getting an OS setup to check on it. Have you tried this NIC on anything previously, an older release? Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Re[6]: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
On Nov 15, 2007 12:54 PM, Lev Serebryakov [EMAIL PROTECTED] wrote: Hello, Jack. You wrote 15 ?? 2007 ?., 23:52:36: Have you tried this NIC on anything previously, an older release? No... And I don't have spare computer for such test :( OK, then we really have no control in the experiment, it could be bad hardware. Anyway, lets see if I can reproduce anything in our lab, hopefully will know before the end of the day. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[6]: 6.3-PRERELEASE: interrupt storm detected on irq11:; throttling interrupt source, (irq11 is em0)
Hello, Jack. You wrote 15 ?? 2007 ?., 23:52:36: Have you tried this NIC on anything previously, an older release? No... And I don't have spare computer for such test :( -- // Black Lion AKA Lev Serebryakov [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenBSM 1.0 and many audit cleanups/changes merged to 6-STABLE for 6.3
Dear 6.x users: In preparation for FreeBSD 6.3, Christian and I have been merging a moderate number of OpenBSM and audit-related changes from HEAD to RELENG_6. I believe we're now about done in time for the next 6.3 BETA, so if I could ask all users of audit in 6-STABLE to slide forward and test out the changes, that would be most helpful. Most should, in theory, be transparent as they are largely bug fixes and cleanups, so what we're really looking for are any problems that need to be resolved before the release. The OpenBSM commit message is below, but you can check the back commit logs for other changes to src/sys/security/audit in support or related to this. Thanks, Robert N M Watson Computer Laboratory University of Cambridge -- Forwarded message -- Date: Thu, 15 Nov 2007 19:27:12 + (UTC) From: Robert Watson [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/contrib/openbsm HISTORY Makefile.in README TODO VERSION aclocal.m4 configure configure.ac src/contrib/openbsm/bin Makefile.in src/contrib/openbsm/bin/audit Makefile.in audit.8 audit.c src/contrib/openbsm/bin/auditd Makefile.in audit_warn.c ... rwatson 2007-11-15 19:27:12 UTC FreeBSD src repository Modified files:(Branch: RELENG_6) contrib/openbsm HISTORY Makefile.in README TODO VERSION aclocal.m4 configure configure.ac contrib/openbsm/bin Makefile.in contrib/openbsm/bin/audit Makefile.in audit.8 audit.c contrib/openbsm/bin/auditd Makefile.in audit_warn.c auditd.8 auditd.c auditd.h contrib/openbsm/bin/auditfilterd Makefile.in auditfilterd.8 auditfilterd.c contrib/openbsm/bin/auditreduce Makefile.in auditreduce.1 auditreduce.c contrib/openbsm/bin/praudit Makefile.in praudit.1 praudit.c contrib/openbsm/bsm Makefile.in libbsm.h contrib/openbsm/config config.h config.h.in ltmain.sh contrib/openbsm/etc audit_class audit_control audit_event audit_user audit_warn contrib/openbsm/libbsm Makefile.in au_class.3 au_control.3 au_event.3 au_free_token.3 au_io.3 au_mask.3 au_open.3 au_token.3 au_user.3 audit_submit.3 bsm_event.c bsm_io.c bsm_notify.c bsm_token.c bsm_wrappers.c libbsm.3 contrib/openbsm/man Makefile.in audit.2 audit.log.5 audit_class.5 audit_control.5 audit_event.5 audit_user.5 audit_warn.5 auditctl.2 auditon.2 getaudit.2 getauid.2 setaudit.2 setauid.2 contrib/openbsm/modules Makefile.in contrib/openbsm/modules/auditfilter_noop Makefile.in contrib/openbsm/test Makefile.in contrib/openbsm/test/bsm Makefile.in generate.c contrib/openbsm/test/reference arg32_record data_record file_record in_addr_record ip_record ipc_record iport_record opaque_record path_record process32_record return32_record seq_record subject32_record subject32ex_record subject32ex_token-IPv4 subject32ex_token-IPv6 text_record contrib/openbsm/tools Makefile.in audump.c Added files: (Branch: RELENG_6) contrib/openbsm/compat clock_gettime.h contrib/openbsm/test/reference process32ex_record-IPv4 process32ex_record-IPv6 process32ex_token-IPv4 process32ex_token-IPv6 process64_record process64_token process64ex_record-IPv4 process64ex_record-IPv6 process64ex_token-IPv4 process64ex_token-IPv6 zonename_record zonename_token Removed files: (Branch: RELENG_6) contrib/openbsm/test/reference process32ex_record process32ex_token Log: Merge OpenBSM 1.0 from HEAD to RELENG_6: OpenBSM 1.0 - Fix bug in auditreduce(8) which resulted in a memory fault/crash when the user specified an event name with -m. - Remove AU_.* hard-coded audit class constants, as udit classes are now entirely dynamically configured using /etc/security/audit_class. OpenBSM 1.0 alpha 15 - Fix bug when processing in_addr_ex tokens. - Restore the
Re: FreeBSD 6.3 or FreeBSD 7.0
On Wed, 14 Nov 2007, Ivan Voras wrote: Marko Lerota wrote: I see that 6.3 and 7.0 is comming. Now I'm using 6.2-RELEASE for my servers. To what should I upgrade? Which of them will be stable or production release? For low-loaded machines, 7.0 is stable enough even with all the new goodies like ZFS, tmpfs, ULE - I have such a machine with almost 30 days uptime and have done 24h+ stress testing on another machine before blessing it for production - but I still wouldn't trust it for mission critical heads will roll type of servers. If you can, try it on a spare or lightly loaded server, it's worth it. It's probably worth pointing out three more things: (1) Quite a bit of the work in 7.x has also had to do with improving stability; for example, I've spent a significant amount of time restructuring socket and netinet-layer code to reduce its vulnerability to TCP race conditions that earlier in the 6.x life cycle could lead to panics under high load with man TCP resets in flight. These are papered over in 6.x in a less clean way because the changes to address the underlying source of the problems required significant changes I felt too aggressive to merge to 6.x. So while 7.x comes with potentially destablizing new features, it also comes with a lot of cleanup relative to 6.x that should have net stability benefits (at least in the long run). (2) The areas I would particularly stay away from in sensitive production servers are things like new file systems (ZFS), where the chances and consequences of failure may be greater. (3) At least for now, a 7.x kernel works quite well with a 6.x user space, so if you want to try out the 7.x kernel to see how it runs for you, you can do that without disrupting your application installs. You won't be able to use features like ZFS that depend on new userland tools and libraies, but you will be able to evaluate stability and performance for most base OS features. 7.0 is a .0 release, but I think it's also a really strong .0 release. While I might hesitate to recommend ZFS in less experimental settings, I feel that the 7.0 kernel will prove to be one of our most stable, not to mention most performant, .0 releases to date. I would encourage people to try it out and see how it goes for them, but as with all new releases, to do it with adequate caution and a fallback plan in the event you run into something that hasn't been found or addressed in testing to date. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.3 or FreeBSD 7.0
On Thu, 15 Nov 2007, Robert Watson wrote: 7.0 is a .0 release, but I think it's also a really strong .0 release. While I might hesitate to recommend ZFS in less experimental settings, I feel that the 7.0 kernel will prove to be one of our most stable, not to mention most performant, .0 releases to date. I would encourage people to try it out and see how it goes for them, but as with all new releases, to do it with adequate caution and a fallback plan in the event you run into something that hasn't been found or addressed in testing to date. And as a last followup to this: please do run our betas, especially on test servers or servers that fail over -- we won't be able to fix problems we don't hear about, so if you can help us exercise 7.0 now, we can get these things fixed for 7.0 rather than for 7.1 :-). Even if you're just booting up and installing on a spare box and banging it with your web load and mysql load, that sort of testing is invaluable. Breadth of testing is very important to help even out the release. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
