Panic with umass (with USB tape and Amanda)
Hello everybody,
I have just had a panic on 6.2 amd64 box with ehci connected USB DDS4
tape drive while it was for the first time being accessed with Amanda. I
have previously successfully tested it with tar.
I have a kernel crash dump with the following information:
panic: trying to sleep while sleeping is prohibited
cpuid = 0
KDB: stack backtrace:
panic() at panic+0x250
sleepq_add() at sleepq_add+0x225
msleep() at msleep+0x132
bwait() at bwait+0x55
swap_pager_putpages() at swap_pager_putpages+0x45c
vm_pageout_flush() at vm_pageout_flush+0x13b
vm_contig_launder_page() at vm_contig_launder_page+0xdc
vm_page_alloc_contig() at vm_page_alloc_contig+0x321
contigmalloc() at contigmalloc+0x5f7
bus_dmamem_alloc() at bus_dmamem_alloc+0x80
usb_block_allocmem() at usb_block_allocmem+0x118
usb_allocmem() at usb_allocmem+0x13e
usbd_transfer() at usbd_transfer+0xf1
umass_setup_transfer() at umass_setup_transfer+0x3b
umass_bbb_state() at umass_bbb_state+0xc0
usb_transfer_complete() at usb_transfer_complete+0x217
uhci_softintr() at uhci_softintr+0x100
uhci_intr1() at uhci_intr1+0x152
ithread_loop() at ithread_loop+0x148
fork_exit() at fork_exit+0xbb
fork_trampoline() at fork_trampoline+0xe
bt full
#0 0x8027ca40 in shutdown_conf (unused=0x0)
at ../../../kern/kern_shutdown.c:138
No locals.
#1 0x8027d304 in boot (howto=-2004318071)
at ../../../kern/kern_shutdown.c:209
_ep = (struct eventhandler_entry *) 0x0
_el = (struct eventhandler_list *) 0xff007b84c800
first_buf_printf = 1
#2 0x8027cd9b in panic (
fmt=0x803dfa78 trying to sleep while sleeping is
prohibited)
at ../../../kern/kern_shutdown.c:542
bootopt = 260
newpanic = 1
ap = {{gp_offset = 8, fp_offset = 48,
overflow_arg_area = 0xb197a650,
reg_save_area = 0xb197a570}}
buf = trying to sleep while sleeping is prohibited, '\0'
repeats 211 times
#3 0x8029f02a in sleepq_switch (wchan=0x0)
at ../../../kern/subr_sleepqueue.c:447
No locals.
#4 0x8028337c in msleep (ident=0x80560b40, mtx=0x0,
priority=68, wmesg=0x803ef69a swwrt, timo=0)
at ../../../kern/kern_synch.c:133
p = (struct proc *) 0x9f826428
catch = 0
rval = -2141828960
flags = -2141828960
#5 0x802cd1d6 in vfs_unbusy_pages (bp=0x803ef69a)
at ../../../kern/vfs_bio.c:3227
i = 0
obj = 0x1
m = 0x9f826428
#6 0x8034b691 in swap_pager_copy
(srcobject=0xff007fd8a570,
dstobject=0x0, offset=18446742974451804800, destroysource=-1)
at ../../../vm/swap_pager.c:766
i = 18446744072394090256
#7 0x80361a70 in vm_pageout_object_deactivate_pages (
pmap=0xb197a810, first_object=0xff000f21ea80,
desired=-1315461200) at ../../../vm/vm_pageout.c:539
backing_object = 0x802cd1d6
object = 0x1
p = 0x802cd1d6
next = 0xb197a710
actcount = -1
rcount = 0
remove_mode = -1315461232
#8 0x80351338 in vm_page_release_contigl
(m=0xff000f21ea80,
count=18446742976342828400) at ../../../vm/vm_contig.c:353
No locals.
#9 0x803518b3 in contigmalloc (size=0, type=0x,
flags=-256,
low=32768, high=1048575, alignment=505970,
boundary=18446742976282112000)
at ../../../vm/vm_contig.c:579
ret = (void *) 0x7b872
pages = 0x1
npgs = 4503560972664832
#10 0x80352040 in contigmalloc (size=0,
type=0x80521d20,
flags=1, low=0, high=4294967295, alignment=0, boundary=0)
at ../../../vm/vm_contig.c:546
ret = (void *) 0x0
pages = 0xff0076a46860
npgs = 8
#11 0x80368f3d in alloc_bounce_pages (dmat=0x0,
numpages=1457574160)
at ../../../amd64/amd64/busdma_machdep.c:1061
---Type return to continue, or q return to quit---
bpage = (struct bounce_page *) 0x1
bz = (struct bounce_zone *) 0xff000978ed00
count = 1
#12 0x802379ff in usb_block_allocmem (tag=0xff0056e0d100,
size=0,
align=32768, dmap=0xff0076a46860)
at ../../../dev/usb/usb_mem.c:187
p = (usb_dma_block_t *) 0x0
#13 0x80237bba in usb_allocmem (bus=0x0, size=32768, align=0,
p=0xff0076a46860) at ../../../dev/usb/usb_mem.c:248
tag = 0x0
err = USBD_NORMAL_COMPLETION
f = (struct usb_frag_dma *) 0x0
b = (usb_dma_block_t *) 0xb197aaa0
i = 0
#14 0x80239c5a in usbd_transfer (xfer=0xff0076a46800)
at ../../../dev/usb/usbdi.c:311
bus = (struct usbd_bus *) 0x0
pipe = 0xff00132bb500
err = 1540196352
size = 32768
#15 0x80233fa9 in umass_setup_transfer (sc=0x0, pipe=0x0,
buffer=0x0,
buflen=0, flags=0, xfer=0xff0076a46800)
at ../../../dev/usb/umass.c:1252
err = USBD_NORMAL_COMPLETION
#16 0x802344c0 in
em(4) interface freezing on 6.2
Hello, I have got Dell PowerEdge 750 with on-board em(4) network cards and I use it as a router. The interface em0 stops forwarding traffic from time to time. Resetting the interface with ifconfig down up fixes the problem. [EMAIL PROTECTED]:1:0: class=0x02 card=0x01651028 chip=0x10758086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82547EI Gigabit Ethernet Controller' class= network subclass = ethernet em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xece0-0xecff mem 0xfe2e-0xfe2f irq 18 at device 1.0 on pci1 em0: Reserved 0x2 bytes for rid 0x10 type 3 at 0xfe2e em0: Reserved 0x20 bytes for rid 0x18 type 4 at 0xece0 em0: bpf attached em0: Ethernet address: 00:14:22:7a:1c:10 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 49 em0: [MPSAFE] I am running RELENG_6_2, with CARP. PF with traffic normalization is active (scrub in all fragment reassemble). I have tried turning off checksum offload. When the interface does not pass traffic it looks normal in ifconfig(8). ARP does not work and nothing interesting get written to the logs. em0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 options=bRXCSUM,TXCSUM,VLAN_MTU inet 192.168.1.8 netmask 0xfff0 broadcast 192.168.1.15 ether 00:14:22:7a:1c:10 media: Ethernet autoselect (1000baseTX full-duplex) status: active The machine is processing couple of megabits worth of traffic all the time and it takes anywhere from an hour to more than a day to occur. I had about 10 interface freezes on em0 interface but none on em1. When I put additional network card into the machine (xl(4)) and use it together with em1 it works without a problem. The only difference between em0 and em1 there I can think of is that there may be some out-of-band management functions in the em0 which driver does not correctly turn of or something. I have noticed a small update to the driver in -STABLE but I don't think this could fix my issues. Due to the nature of the problem and use of the machine I am afraid I can not do much to help narrow the problem further down. Thank you Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em, bge, network problems survey.
Kris Kennaway wrote: On Fri, Oct 06, 2006 at 08:54:35AM +0200, Michal Mertl wrote: Kris Kennaway wrote: On Wed, Oct 04, 2006 at 05:14:27PM -0600, Scott Long wrote: All, I'm seeing some patterns here with all of the network driver problem reports, but I need more information to help narrow it down further. I ask all of you who are having problems to take a minute to fill out this survey and return it to Kris Kennaway (on cc:) and myself. Thanks. 1. Are you experiencing network hangs and/or timeout messages on the console? If yes, please provide a _brief_ description of the problem. OK, next question, to all em users: If your em device is using a shared interrupt, and you are NOT experiencing timeout problems when using this device, please let me know. I haven't seen any timeout message in long time but I experience frozen network (and also the already reported panic when doing ifconfig down/up then). Are these details in a PR? I don't know. As I have seen somebody else reporting the same issue (even with backtrace) and the problem was believed to be understood I dind't pay much attention, sorry. I have also seen strange problem which may be completely unrelated: When doing 'find . -ls' on SMB mounted drive - find was spitting the contents of the drive but never finishes. Network seemed dead but when I interrupted find with Ctrl-C I got the replies to the pings sent when it was running (e.g. thousands ms) - this looks like something was preventing RX to work and the packets were just queued somewhere. I belive I should be able to easily reproduce it. genius# vmstat -i interrupt total rate irq0: clk 43784465 1000 irq1: atkbd0 66248 1 irq5: pcm0 5877 0 irq8: rtc5603682128 irq9: acpi0 8820 0 irq11: fwohci0 em*205749 4 irq12: psm0 586848 13 irq14: ata0 340844 7 irq15: ata1 61 0 Total 50602594 1155 I don't think I remember debug.mpsafenet tunable being mentioned in the threads about the problems. It prevents all the problems on my system (UP non-APIC system), including the SMB issue mentioned above. I suspect both of your problems are some unrelated issue. I'd need root access a test setup before I can say more though. It is possible, but your patch to change INTR_FAST to INTR_MPSAFE seems to help with both of these too. I am planning to try to reproduce the SMB temporary network lockup (with original CURRENT driver) and probably do a panic then to get a core. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em, bge, network problems survey.
Michal Mertl wrote: Kris Kennaway wrote: On Wed, Oct 04, 2006 at 05:14:27PM -0600, Scott Long wrote: All, I'm seeing some patterns here with all of the network driver problem reports, but I need more information to help narrow it down further. I ask all of you who are having problems to take a minute to fill out this survey and return it to Kris Kennaway (on cc:) and myself. Thanks. 1. Are you experiencing network hangs and/or timeout messages on the console? If yes, please provide a _brief_ description of the problem. OK, next question, to all em users: If your em device is using a shared interrupt, and you are NOT experiencing timeout problems when using this device, please let me know. I forgot to note I am running fresh current, not stable. I haven't seen any timeout message in long time but I experience frozen network (and also the already reported panic when doing ifconfig down/up then). I have also seen strange problem which may be completely unrelated: When doing 'find . -ls' on SMB mounted drive - find was spitting the contents of the drive but never finishes. Network seemed dead but when I interrupted find with Ctrl-C I got the replies to the pings sent when it was running (e.g. thousands ms) - this looks like something was preventing RX to work and the packets were just queued somewhere. I belive I should be able to easily reproduce it. genius# vmstat -i interrupt total rate irq0: clk 43784465 1000 irq1: atkbd0 66248 1 irq5: pcm0 5877 0 irq8: rtc5603682128 irq9: acpi0 8820 0 irq11: fwohci0 em*205749 4 irq12: psm0 586848 13 irq14: ata0 340844 7 irq15: ata1 61 0 Total 50602594 1155 I don't think I remember debug.mpsafenet tunable being mentioned in the threads about the problems. It prevents all the problems on my system (UP non-APIC system), including the SMB issue mentioned above. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic with PF
Max Laier píše v pá 21. 07. 2006 v 02:05 +0200: [CC'ing -pf] On Thursday 20 July 2006 17:53, Michal Mertl wrote: Hello, I am deploying FreeBSD based application proxies' based firewall (www.kernun.com, but not much English there) and am having frequent panics of RELENG_6_1 under load. The server has IP forwarding disabled. I've got two machines in a carp cluster and the transparent proxies use PF to get the data. Which proxies are you using? The pool_ticket: 1429 != 1430 messages you quote below indicate a synchronization problem within the app talking to pf via ioctl's. Tickets are used to ensure atomic commits for operations that require more than one ioctl. If your proxy app runs in parallel it might screw up the internal state and thus leave it undefined afterwards. I give you that this shouldn't cause a kernel problem, but if we could fix the app we can probably find the right sanity check more easily. The proxy in fact runs in parallel (according to pfctl -s info it did about 50 inserts and removal in the state table per second - some 10Mbit of traffic, probably mostly HTTP) and it is quite possible that your explanation is correct. I will forward your suspicion to the vendor. This functionality of the software (using PF with anchors) is quite new - they used different mechanisms in previous versions so it may well have some bugs. Thanks Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic with PF
Daniel Hartmeier wrote: On Fri, Jul 21, 2006 at 02:05:45AM +0200, Max Laier wrote: Which proxies are you using? The pool_ticket: 1429 != 1430 messages you quote below indicate a synchronization problem within the app talking to pf via ioctl's. Tickets are used to ensure atomic commits for operations that require more than one ioctl. If your proxy app runs in parallel it might screw up the internal state and thus leave it undefined afterwards. I give you that this shouldn't cause a kernel problem, but if we could fix the app we can probably find the right sanity check more easily. This looks like a bug in pf_ioctl.c pfioctl() DIOCCHANGERULE if (newrule-action == PF_NAT) || (newrule-action == PF_RDR) || (newrule-action == PF_BINAT) || (newrule-rt PF_FASTROUTE)) - !pcr-anchor[0])) + !newrule-anchor)) (TAILQ_FIRST(newrule-rpool.list) == NULL)) error = EINVAL; i.e. the pool must not be empty for routing and translation rules, except for translation rules that are actually anchor _calls_. The confusion is between translation rules within anchors (pcr-anchor[0] != '\0') and calls to anchors' translation rules (rule-anchor != NULL). If the proxy is using DIOCCHANGERULE (it must be the proxy, pfctl isn't using it at all), AND is trying to add/update a rule that requires at least one replacement address but contains an empty list, then this would cause the panic seen when that rule later matches a packet. This needs fixing in OpenBSD as well. Michal, can you please confirm that the patch above fixes the panic? The proxy will still misbehave and cause the log messages (one more EINVAL in this case ;), but the kernel shouldn't crash anymore. I am afraid I can't test it at the moment. I am going to get one of the machines to my lab and will experiment with it there. I am afraid I will have problems generating enough traffic for the problem to appear but I will try. Thanks for the excellent bug report! Thank you. I don't think is was that good as I now see that you had to guess there are anchors used. The rules look like this (except the rules seen by 'pfctl -s nat' they are generated by the proxies when they start): fw1#pfctl -s rule fw1#pfctl -s nat nat-anchor /kernun/* all rdr-anchor /kernun/* all fw1#pfctl -s Anchors -v kernun kernun/4026 kernun/4039 kernun/4088 kernun/4112 kernun/4134 kernun/4164 kernun/4197 kernun/4257 kernun/4296 kernun/4338 kernun/4383 kernun/4431 kernun/4482 kernun/4590 kernun/4649 fw1# pfctl -a kernun/4039 -s nat rdr on em0 inet proto tcp from any to any port = http label HTTP - 127.0.0.1 When the system was under load I saw ~5000 states in 'pfctl -s state'. Thank you again. I will let you know when I get a chance to test your patch and or find out anything new. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Kernel panic with PF
Daniel Hartmeier wrote: On Fri, Jul 21, 2006 at 10:57:28AM +0200, Michal Mertl wrote: The proxy in fact runs in parallel (according to pfctl -s info it did about 50 inserts and removal in the state table per second - some 10Mbit of traffic, probably mostly HTTP) and it is quite possible that your explanation is correct. I will forward your suspicion to the vendor. This functionality of the software (using PF with anchors) is quite new - they used different mechanisms in previous versions so it may well have some bugs. Anchors were introduced for this purpose, i.e. splitting the ruleset into separate pieces, over each of which a single process can have authority, so different processes don't stomp on each other's toes with ruleset modifications. They (the Kernun authors) run multiple processes for each proxy. Originally they used slightly modified Apached core for their proxies I believe. Thus there are probably more processes using the same anchor. I don't really understand what they do inside - I would think that when there are no traffic blocking rules, there's no point in doing anything with PF except initial setting of the rdr rule to the proxy. Ask them if they really need to still use DIOCCHANGERULE, as the idea with anchors is generally to only operate within one anchor, and usually flush or replace the (smaller) ruleset within. Each anchor has its own ticket, so if you're seeing ticket mismatches, that means there are concurrent operations on the same anchor, even. I see. It would be better if they were part of this communication because I don't know the internals (although I have the source code). I have problems reaching them at the moment though. Daniel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel panic with PF
Hello,
I am deploying FreeBSD based application proxies' based firewall
(www.kernun.com, but not much English there) and am having frequent
panics of RELENG_6_1 under load. The server has IP forwarding disabled.
I've got two machines in a carp cluster and the transparent proxies use
PF to get the data.
I don't know much about kernel internals and PF but from the following
backtrace I understand that the crash happens because rpool-cur on line
2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It
probably shouldn't happen yet it does.
The machines are SMP and were running SMP kernel. The only places where
pool.cur (or pool-cur) is assigned to are in pf_ioctl.c. It seems there
are some lock operations though so it is probably believed that the
coder is properly locked.
I have been running with kern.smp.disabled=1 for a moment before I put
the old firewall in place and haven't seen the panic but the time was
deffinitely too short to make me believe it fixes the issue. Can setting
debug.mpsafenet to 0 possibly also help?
I could probably bandaid this particular failure mode by returning
failure instead of panicing but the bug is probably elsewhere.
I've lost the debug kernel from which this backtrace is and can't
therefore continue much :-(. Unfortunately so far I can only reproduce
the problem in production and for obvious reasons I can't put it there.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x28
fault code = supervisor read, page not present
instruction pointer = 0x8:0x801ab528
stack pointer = 0x10:0xb1ade650
frame pointer = 0x10:0xff004cc7cc30
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 15 (swi1: net)
trap number = 12
panic: page fault
#0 doadump () at pcpu.h:172
#1 0x0004 in ?? ()
#2 0x803d5137 in boot (howto=260)
at ../../../kern/kern_shutdown.c:402
#3 0x803d58a1 in panic (fmt=0xff007ba32000 @\223A3{)
at ../../../kern/kern_shutdown.c:558
#4 0x80543b3f in trap_fatal (frame=0xff007ba32000,
eva=18446742976272241472) at ../../../amd64/amd64/trap.c:660
#5 0x80543e5f in trap_pfault (frame=0xb1ade5a0,
usermode=0)
at ../../../amd64/amd64/trap.c:573
#6 0x80544113 in trap (frame=
{tf_rdi = 2, tf_rsi = -1098223465792, tf_rdx = -1098439497700,
tf_rcx = -1
314002464, tf_r8 = 0, tf_r9 = -1314002776, tf_rax = 0, tf_rbx = 0,
tf_rbp = -109
8223465424, tf_r10 = 1, tf_r11 = 257, tf_r12 = -1098439497700, tf_r13 =
-1314002
776, tf_r14 = 2, tf_r15 = -1314002464, tf_trapno = 12, tf_addr = 40,
tf_flags =
216171684640539392, tf_err = 0, tf_rip = -214576, tf_cs = 8,
tf_rflags = 661
18, tf_rsp = -1314003360, tf_ss = 16})
at ../../../amd64/amd64/trap.c:352
#7 0x8052feab in calltrap ()
at ../../../amd64/amd64/exception.S:168
#8 0x801ab528 in pf_map_addr (af=2 '\002',
r=0xff004cc7cac0,
saddr=0xff003fe7681c, naddr=0xb1ade9e0, init_addr=0x0,
sn=0xb1ade8a8) at ../../../contrib/pf/net/pf.c:2163
#9 0x801acab6 in pf_get_translation (pd=0xb1ade9c0,
m=0xff0042ede900, off=20, direction=1, kif=0xff007b038a00,
sn=0xb1ade8a8, saddr=0xff003fe7681c, sport=0,
daddr=0xff003fe76820, dport=50881, naddr=0xb1ade9e0,
nport=0xb1ade8b6) at ../../../contrib/pf/net/pf.c:2618
#10 0x801b315b in pf_test_tcp (rm=0xb1ade960,
sm=0xb1ade950, direction=1, kif=0xff007b038a00,
m=0xff0042ede900, off=20, h=0xff003fe76810,
pd=0xb1ade9c0, am=0xb1ade968,
rsm=0xb1ade970,
ifq=0x2, inp=0x0) at ../../../contrib/pf/net/pf.c:3013
#11 0x801b5694 in pf_test (dir=1, ifp=0xffbee800,
m0=0xb1adeaa0, eh=0xb1ade97e, inp=0x0)
at ../../../contrib/pf/net/pf.c:6449
#12 0x801bafb2 in pf_check_in (arg=0x2, m=0xb1adeaa0,
ifp=0xff004cc7cac0, dir=-1314002464, inp=0xb1ade9e0)
at ../../../contrib/pf/net/pf_ioctl.c:3358
#13 0x80461c2e in pfil_run_hooks (ph=0x807e0920,
mp=0xb1adeb28, ifp=0xffbee800, dir=1, inp=0x0)
at ../../../net/pfil.c:139
#14 0x8048d225 in ip_input (m=0xff0042ede900)
at ../../../netinet/ip_input.c:465
#15 0x8046180c in netisr_processqueue (ni=0x807df690)
at ../../../net/netisr.c:236
#16 0x80461abd in swi_net (dummy=0x2)
at ../../../net/netisr.c:349
#17 0x803bbd99 in ithread_loop (arg=0xff0506a0)
at ../../../kern/kern_intr.c:684
#18 0x803ba527 in fork_exit (
callout=0x803bbc50 ithread_loop, arg=0xff0506a0,
frame=0xb1adec50) at ../../../kern/kern_fork.c:805
Re: Kernel panic with PF
Michael Proto wrote: Michal Mertl wrote: Hello, I am deploying FreeBSD based application proxies' based firewall (www.kernun.com, but not much English there) and am having frequent panics of RELENG_6_1 under load. The server has IP forwarding disabled. I've got two machines in a carp cluster and the transparent proxies use PF to get the data. I don't know much about kernel internals and PF but from the following backtrace I understand that the crash happens because rpool-cur on line 2158 in src/sys/contrib/pf/net/pf.c is NULL and is dereferenced. It probably shouldn't happen yet it does. The machines are SMP and were running SMP kernel. The only places where pool.cur (or pool-cur) is assigned to are in pf_ioctl.c. It seems there are some lock operations though so it is probably believed that the coder is properly locked. I have been running with kern.smp.disabled=1 for a moment before I put the old firewall in place and haven't seen the panic but the time was deffinitely too short to make me believe it fixes the issue. Can setting debug.mpsafenet to 0 possibly also help? ... Are you using user and/or group rules in your PF ruleset? If so, then you will want to set debug.mpsafenet to 0 as its a known issue with pf(4) currently. Thank you. No, I am not using it and I am quite sure the proxies aren't doing it behind my back either. In fact there isn't a single entry in the rules tables - there are only rdr rules generated on the fly by the proxies. I will try to set this (in addition to running UP) to see whether it helps anyway. Thanks Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Temperature monitoring in FreeBSD 4/5/6
O. Hartmann wrote: O. Hartmann schrieb: Roland Smith schrieb: On Thu, Mar 16, 2006 at 07:22:14PM -0500, Stephan Koenig wrote: Does anyone know of an easy way to get temperature information out of a Dell PowerEdge 1550/1650/1750/1850/2650/2850 running FreeBSD4/5/6? Something that has a very simple CLI that just outputs the temperature without any formatting, or a library/sysctl, would be ideal. /usr/ports/sysutils/mbmon If you want an additional X frontend, try /usr/ports/sysutils/xmbmon Roland This port does not work for me on any DELL Optiplex GX270/280 and 820 around here. Especially on GX270/280 I tried every knob of the port I found without a positive result. Oliver It does also not work on ASUS A8N32-SLI due to an unsupported chipset. O. On one machine where mbmon doesn't report anything useful lmmon does. HTH Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem??
Johan Ström wrote: Hi! On 18 nov 2005, at 18.43, Xin LI wrote: Hi, Johan, large snip So, it seems it does run savecore after running dumpon and mounting disks etc... Is that wrong? No, this is normal. When you run savecore you need to have mounted filesystems. In order to mount the filesystems they may have to be checked. The fsck program requires big amount of memory to check larger filesystems so the swap has to be enabled. Core dumps are written to the dump device (swap) from the end whereas the swap is normally used from the beginning (or the other way around). Therefore there's quite a big chance that, even when the swap has to be used for fsck, the core dump is intact and usable. If the usage of the swap file by fsck corrupts the core dump you may start after next crash in single user mode and run the commands manually (without enabling swap). As to why you can write kernel core dumps only to certain devices the answer is that at the time, when the kernel is dumping core, it is usually in pretty bad state, kernel internals may be corrupted and so on. The dumping code is therefore written to be quite low level so that even wedged kernel can be dumped. The dumping code is part of hard disk controller's drivers. The gmirror is quite high-level device and geom itself needs working scheduler so there will probably never be a way to dump on gmirror provided swap. When you issue the dumpon command the check is performed whether the driver for the disk you want to dump on supports kernel core dumps. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Page fault, GEOM problem??
Parv wrote: in message [EMAIL PROTECTED], wrote Michal Mertl thusly... Johan Ström wrote: On 18 nov 2005, at 18.43, Xin LI wrote: ... So, it seems it does run savecore after running dumpon and mounting disks etc... Is that wrong? No, this is normal. When you run savecore you need to have mounted filesystems. In order to mount the filesystems they may have to be checked. The fsck program requires big amount of memory to check larger filesystems so the swap has to be enabled. Core dumps are written to the dump device (swap) from the end whereas the swap is normally used from the beginning (or the other way around). Therefore there's quite a big chance that, even when the swap has to be used for fsck, the core dump is intact and usable. Is there any formula to calculate the size of swap to account for fsck core dump while assigning swap size (short of having two swap partitions)? None that I know of. Someone posted to some FreeBSD mailing list some figures about the fsck consumption of memory. I really don't remember, but I think it was something like some MBs of memory per quite a lot of GB of file system space. E.g. that the fsck on normally sized file systems (e.g. at most a couple of hundred GB) doesn't normally cosume all of normally sized memory (=256MB) and thus doesn't need to swap. If the usage of the swap file by fsck corrupts the core dump you may start after next crash in single user mode and run the commands manually (without enabling swap). Is that after kernel (re)boots? And would the commands to be executed be savecore followed by swapon? If the dump got corrupted by fsck, you would have to wait for another crash and dump. Then you would reboot and start in single user mode, repair the file systems without swap enabled (fsck would crash on the large file system(s)) and then run savecore. Swapon is then irrelevant, you probably don't need swap for savecore. After running savecore you can start normally multi user (exit from the single user shell). I didn't try all of that but I believe it should work. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB JetFlash
Mikhail Godovitcin wrote: I believe I should be able to help you. I've got smaller JetFlash which works. Yours might need a quirk entry in umass.c. Can you send us the output of 'usbdevs -v'? Hello! FreeBSD 5.4-PRERELEASE #0: Mon Mar 21 12:07:18 MSK 2005 JetFlash TS512MJF2B 2.00 (512Mb) works well: umass0: USB Flash Disk, rev 2.00/2.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: JetFlash TS512MJF2B 2.00 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: 500MB (1024000 512 byte sectors: 64H 32S/T 500C) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached but JetFlash TS1GJF2B 2.00 produses many errors: da0: Attempt to query device size failed: UNIT ATTENTION, Not ready to ready change, (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 and so on until (da0:umass-sim0:0:0:0): Retries Exhausted Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (da0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (da0:umass-sim0:0:0:0): Retrying Command (per Sense Data) umass0: at uhub0 port 1 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached How can I fix this? Thanks in advance. -- Mikhail Godovitcin http://www.kc.ru/~mg/pgpkey.txt ___ 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]: USB JetFlash
Mikhail Godovitcin wrote:
Hello!
Thursday, March 31, 2005, 16:48, you wrote:
I believe I should be able to help you. I've got smaller JetFlash which
works. Yours might need a quirk entry in umass.c.
Can you send us the output of 'usbdevs -v'?
Yes, sure. Here it is.
# usbdevs -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x),
Intel(0x), rev 1.00
port 1 addr 2: full speed, power 100 mA, config 1, Flash Disk(0x2168),
USB(0x0ea0), rev 2.00
port 2 powered
# camcontrol inquiry da0
pass0: JetFlash TS1GJF2B 2.00 Removable Direct Access SCSI-2 device
pass0: Serial Number
pass0: 1.000MB/s transfers
Thank you.
I'm afraid I can't easily help you because your device is different than
mine.
You can try attached patch anyways. Apply with 'cd /sys/dev/usb;patch
jmtek.diff;cd /sys/modules/umass;make -DUSB_DEBUG=1;make unload;make
load'.
I won't be surprised if it didn't fix your disk though. You might try to
change UMASS_ADD_DELAY in
{ USB_VENDOR_OTI, USB_PRODUCT_OTI_JETFLASH2, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
UMASS_ADD_DELAY
},
to 'IGNORE_RESIDUE | NO_GETMAXLUN | RS_NO_CLEAR_UA'. Maybe
FORCE_SHORT_INQUIRY instead/in addition to these.
After modifying umass.c you need to rebuild and unloadload the kld. If
you have umass (or whole usb) in your kernel ('device umass') you should
comment it out, reinstall kernel and reboot. Then you'll be able to try
different quirk values.
HTH
Michal
Index: umass.c
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/umass.c,v
retrieving revision 1.121
diff -u -r1.121 umass.c
--- umass.c 25 Mar 2005 01:47:01 - 1.121
+++ umass.c 31 Mar 2005 19:53:51 -
@@ -314,6 +314,8 @@
# define NO_INQUIRY 0x0400
/* Device cannot handle INQUIRY EVPD, return CHECK CONDITION */
# define NO_INQUIRY_EVPD 0x0800
+ /* Device needs time to settle down - should be fixed elsewhere*/
+# define UMASS_ADD_DELAY 0x1000
};
Static struct umass_devdescr_t umass_devdescrs[] = {
@@ -387,6 +389,10 @@
UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
NO_QUIRKS
},
+ { USB_VENDOR_MSYSTEMS, USB_PRODUCT_MSYSTEMS_DELLMEMKEY, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ UMASS_ADD_DELAY
+ },
{ USB_VENDOR_NEODIO, USB_PRODUCT_NEODIO_ND3260, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
FORCE_SHORT_INQUIRY
@@ -399,6 +405,10 @@
UMASS_PROTO_ATAPI | UMASS_PROTO_BBB,
NO_INQUIRY | NO_GETMAXLUN
},
+ { USB_VENDOR_OTI, USB_PRODUCT_OTI_JETFLASH2, RID_WILDCARD,
+ UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
+ UMASS_ADD_DELAY
+ },
{ USB_VENDOR_PANASONIC, USB_PRODUCT_PANASONIC_KXLCB20AN, RID_WILDCARD,
UMASS_PROTO_SCSI | UMASS_PROTO_BBB,
NO_QUIRKS
@@ -891,6 +901,7 @@
(void) umass_match_proto(sc, sc-iface, uaa-device);
id = usbd_get_interface_descriptor(sc-iface);
+
#ifdef USB_DEBUG
printf(%s: , USBDEVNAME(sc-sc_dev));
switch (sc-protoUMASS_PROTO_COMMAND) {
@@ -2263,6 +2274,7 @@
Static int
umass_cam_attach(struct umass_softc *sc)
{
+ int delay_len;
#ifndef USB_DEBUG
if (bootverbose)
#endif
@@ -2279,7 +2291,11 @@
* completed, when interrupts have been enabled.
*/
- usb_callout(sc-cam_scsi_rescan_ch, MS_TO_TICKS(200),
+ if (sc-quirks UMASS_ADD_DELAY)
+ delay_len = 2000;
+ else
+ delay_len = 200;
+ usb_callout(sc-cam_scsi_rescan_ch, MS_TO_TICKS(delay_len),
umass_cam_rescan, sc);
}
Index: usbdevs
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.226
diff -u -r1.226 usbdevs
--- usbdevs 21 Mar 2005 08:43:54 - 1.226
+++ usbdevs 31 Mar 2005 19:54:21 -
@@ -529,6 +529,7 @@
vendor SITECOM 0x6189 Sitecom
vendor INTEL 0x8086 Intel
vendor HP2 0xf003 Hewlett Packard
+vendor JMTEK 0x0c76 JMTek, LLC.
/*
* List of known products. Grouped by vendor.
@@ -1188,6 +1189,7 @@
/* M-Systems products */
product MSYSTEMS DISKONKEY 0x0010 DiskOnKey
product MSYSTEMS DISKONKEY2 0x0011 DiskOnKey
+product MSYSTEMS DELLMEMKEY 0x0015 Dell Memory Key
/* National Semiconductor */
product NATIONAL BEARPAW1200 0x1000 BearPaw 1200
@@ -1560,3 +1562,9 @@
/* ZyXEL Communication Co. products */
product ZYXEL OMNI56K 0x1500 Omni 56K Plus
product ZYXEL 980N 0x2011 Scorpion-980N keyboard
+
+/* JMTek, LLC. products */
+product JMTEK JETFLASH 0x0005 Transcend JetFlash
+
+/* Ours Technology, Inc. products */
+product OTI JETFLASH2 0x2168 Transcend JetFlash 2.0
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ucom (uplcom) error
Emanuel Strobl wrote: Am Donnerstag, 20. Januar 2005 14:18 schrieb Michal Mertl: I tested my patch for binary safety on CURRENT yesterday (dialed with ppp) and didn't notice any problem. I'm attaching my patch again because some recipients didn't probably receive it yesterday. This didn't apply cleanly against my -stable from today. Attached is a cleaned version (#define RSAQ_STATUS_CTS doesn't exist in -stable uplcom.c) for -stable which compiles for me. Thank you. I found I can't run getty on the converter. I see some output on the remote computer but it stops pretty soon. If I issue setty -f /dev/cuaU0 crtscts I get some more output. It works really realiably in the other direction (running getty on real serial and connecting to it with cu through the converter). I will try to find out more. Michal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ucom (uplcom) error
I wrote:
Emanuel Strobl wrote:
Am Dienstag, 18. Januar 2005 16:17 schrieb Andrew L. Neporada:
On Tue, Jan 18, 2005 at 01:06:43PM +0100, Emanuel Strobl wrote:
Dear experts,
I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working
the other one not (I hate to say it but both are working under win).
The not working (more expensive) one gets recognized as ucom0 and I have
ucom0, also I can receive signal but not transmit.
[skip]
Take a look at http://gate.intercaf.ru/~lesha/6100/ and try patch
http://gate.intercaf.ru/~lesha/6100/pl2303x.patch
It can break old (working) PL2303 chip, but it works for me with newer
Thanks a lot, this indeed fixes the revision 3.0 adaptor but unfortunately
also breakes the 2.02 version :(
Perhaps there's a goog guy out there who can refurbish the uplcom driver
with
this information (akiyama?)?
Thanks a lot,
I've just recently been looking into this too. I used the mentioned
patch and also linux driver source and have come with the attached
patch. It contains one more change but I don't know if it's correct. It
works for both chips on CURRENT for serial console. It detects if the
chip is rev 3.00 and aplies the patch only for it.
The author of the patch mentions it isn't binary safe - sometimes the
chip stops working. I planned to test it with binary transfers (ppp)
today, check if it's working and submit it (with some cleanup) for
inclusion in FreeBSD.
Michal Mertl
I tested my patch for binary safety on CURRENT yesterday (dialed with
ppp) and didn't notice any problem.
I'm attaching my patch again because some recipients didn't probably
receive it yesterday.
Michal
Index: uplcom.c
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.25
diff -u -r1.25 uplcom.c
--- uplcom.c 6 Jan 2005 01:43:29 - 1.25
+++ uplcom.c 20 Jan 2005 13:15:40 -
@@ -97,10 +97,13 @@
#include sys/sysctl.h
#include sys/uio.h
+#include machine/bus.h
+
#include dev/usb/usb.h
#include dev/usb/usbcdc.h
#include dev/usb/usbdi.h
+#include dev/usb/usbdivar.h
#include dev/usb/usbdi_util.h
#include usbdevs.h
#include dev/usb/usb_quirks.h
@@ -113,30 +116,34 @@
SYSCTL_INT(_hw_usb_uplcom, OID_AUTO, debug, CTLFLAG_RW,
uplcomdebug, 0, uplcom debug level);
-#define DPRINTFN(n, x) do { \
+#define DPRINTFN(n, x) do { \
if (uplcomdebug (n)) \
logprintf x; \
} while (0)
#else
-#define DPRINTFN(n, x)
+#define DPRINTFN(n, x)
#endif
-#define DPRINTF(x) DPRINTFN(0, x)
+#define DPRINTF(x) DPRINTFN(0, x)
-#define UPLCOM_MODVER 1 /* module version */
+#define UPLCOM_MODVER 1 /* module version */
#define UPLCOM_CONFIG_INDEX 0
#define UPLCOM_IFACE_INDEX 0
#define UPLCOM_SECOND_IFACE_INDEX 1
#ifndef UPLCOM_INTR_INTERVAL
-#define UPLCOM_INTR_INTERVAL 100 /* ms */
+#define UPLCOM_INTR_INTERVAL 100 /* ms */
#endif
#define UPLCOM_SET_REQUEST 0x01
#define UPLCOM_SET_CRTSCTS 0x41
-#define RSAQ_STATUS_CTS 0x80
-#define RSAQ_STATUS_DSR 0x02
-#define RSAQ_STATUS_DCD 0x01
+#define UPLCOM_SET_CRTSCTS_2303X 0x61
+#define RSAQ_STATUS_CTS 0x80
+#define RSAQ_STATUS_DSR 0x02
+#define RSAQ_STATUS_DCD 0x01
+
+#define CHIPTYPE_PL2303 0
+#define CHIPTYPE_PL2303X 1
struct uplcom_softc {
struct ucom_softc sc_ucom;
@@ -156,14 +163,15 @@
u_char sc_lsr; /* Local status register */
u_char sc_msr; /* uplcom status register */
+ int sc_chiptype;
};
/*
* These are the maximum number of bytes transferred per frame.
* The output buffer size cannot be increased due to the size encoding.
*/
-#define UPLCOMIBUFSIZE 256
-#define UPLCOMOBUFSIZE 256
+#define UPLCOMIBUFSIZE 256
+#define UPLCOMOBUFSIZE 256
Static usbd_status uplcom_reset(struct uplcom_softc *);
Static usbd_status uplcom_set_line_coding(struct uplcom_softc *,
@@ -299,6 +307,7 @@
char *devinfo;
const char *devname;
usbd_status err;
+ usb_device_descriptor_t *udd;
int i;
devinfo = malloc(1024, M_USBDEV, M_WAITOK);
@@ -374,7 +383,14 @@
sc-sc_isize = UGETW(ed-wMaxPacketSize);
}
}
-
+ udd = dev-ddesc;
+ if (UGETW(udd-bcdDevice) == 0x300) {
+ DPRINTF((chiptype 2303X\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303X;
+ } else {
+ DPRINTF((chiptype 2303\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303;
+ }
if (sc-sc_intr_number == -1) {
printf(%s: Could not find interrupt in\n,
USBDEVNAME(ucom-sc_dev));
@@ -617,7 +633,10 @@
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = UPLCOM_SET_REQUEST;
USETW(req.wValue, 0);
- USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
+ if (sc-sc_chiptype == CHIPTYPE_PL2303X)
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS_2303X);
+ else
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
USETW(req.wLength, 0);
err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0);
@@ -713,6 +732,43 @@
return (0);
}
+#define DO_REQ(type, reQ, wVal, wInd) do
Re: strange ucom (uplcom) error
Emanuel Strobl wrote:
Am Dienstag, 18. Januar 2005 16:17 schrieb Andrew L. Neporada:
On Tue, Jan 18, 2005 at 01:06:43PM +0100, Emanuel Strobl wrote:
Dear experts,
I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working
the other one not (I hate to say it but both are working under win).
The not working (more expensive) one gets recognized as ucom0 and I have
ucom0, also I can receive signal but not transmit.
[skip]
Take a look at http://gate.intercaf.ru/~lesha/6100/ and try patch
http://gate.intercaf.ru/~lesha/6100/pl2303x.patch
It can break old (working) PL2303 chip, but it works for me with newer
Thanks a lot, this indeed fixes the revision 3.0 adaptor but unfortunately
also breakes the 2.02 version :(
Perhaps there's a goog guy out there who can refurbish the uplcom driver with
this information (akiyama?)?
Thanks a lot,
I've just recently been looking into this too. I used the mentioned
patch and also linux driver source and have come with the attached
patch. It contains one more change but I don't know if it's correct. It
works for both chips on CURRENT for serial console.
The author of the patch mentions it isn't binary safe - sometimes the
chip stops working. I planned to test it with binary transfers (ppp)
today, check if it's working and submit it (with some cleanup) for
inclusion in FreeBSD.
Michal Mertl
Index: uplcom.c
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.25
diff -u -r1.25 uplcom.c
--- uplcom.c 6 Jan 2005 01:43:29 - 1.25
+++ uplcom.c 15 Jan 2005 00:44:20 -
@@ -97,10 +97,13 @@
#include sys/sysctl.h
#include sys/uio.h
+#include machine/bus.h
+
#include dev/usb/usb.h
#include dev/usb/usbcdc.h
#include dev/usb/usbdi.h
+#include dev/usb/usbdivar.h
#include dev/usb/usbdi_util.h
#include usbdevs.h
#include dev/usb/usb_quirks.h
@@ -113,30 +116,33 @@
SYSCTL_INT(_hw_usb_uplcom, OID_AUTO, debug, CTLFLAG_RW,
uplcomdebug, 0, uplcom debug level);
-#define DPRINTFN(n, x) do { \
+#define DPRINTFN(n, x) do { \
if (uplcomdebug (n)) \
logprintf x; \
} while (0)
#else
-#define DPRINTFN(n, x)
+#define DPRINTFN(n, x)
#endif
-#define DPRINTF(x) DPRINTFN(0, x)
+#define DPRINTF(x) DPRINTFN(0, x)
-#define UPLCOM_MODVER 1 /* module version */
+#define UPLCOM_MODVER 1 /* module version */
#define UPLCOM_CONFIG_INDEX 0
#define UPLCOM_IFACE_INDEX 0
#define UPLCOM_SECOND_IFACE_INDEX 1
#ifndef UPLCOM_INTR_INTERVAL
-#define UPLCOM_INTR_INTERVAL 100 /* ms */
+#define UPLCOM_INTR_INTERVAL 100 /* ms */
#endif
#define UPLCOM_SET_REQUEST 0x01
#define UPLCOM_SET_CRTSCTS 0x41
-#define RSAQ_STATUS_CTS 0x80
-#define RSAQ_STATUS_DSR 0x02
-#define RSAQ_STATUS_DCD 0x01
+#define RSAQ_STATUS_CTS 0x80
+#define RSAQ_STATUS_DSR 0x02
+#define RSAQ_STATUS_DCD 0x01
+
+#define CHIPTYPE_PL2303 0
+#define CHIPTYPE_PL2303X 1
struct uplcom_softc {
struct ucom_softc sc_ucom;
@@ -156,14 +162,15 @@
u_char sc_lsr; /* Local status register */
u_char sc_msr; /* uplcom status register */
+ int sc_chiptype;
};
/*
* These are the maximum number of bytes transferred per frame.
* The output buffer size cannot be increased due to the size encoding.
*/
-#define UPLCOMIBUFSIZE 256
-#define UPLCOMOBUFSIZE 256
+#define UPLCOMIBUFSIZE 256
+#define UPLCOMOBUFSIZE 256
Static usbd_status uplcom_reset(struct uplcom_softc *);
Static usbd_status uplcom_set_line_coding(struct uplcom_softc *,
@@ -299,6 +306,7 @@
char *devinfo;
const char *devname;
usbd_status err;
+ usb_device_descriptor_t *udd;
int i;
devinfo = malloc(1024, M_USBDEV, M_WAITOK);
@@ -374,7 +382,14 @@
sc-sc_isize = UGETW(ed-wMaxPacketSize);
}
}
-
+ udd = dev-ddesc;
+ if (UGETW(udd-bcdDevice) == 0x300) {
+ DPRINTF((chiptype 2303X\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303X;
+ } else {
+ DPRINTF((chiptype 2303\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303;
+ }
if (sc-sc_intr_number == -1) {
printf(%s: Could not find interrupt in\n,
USBDEVNAME(ucom-sc_dev));
@@ -617,7 +632,10 @@
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = UPLCOM_SET_REQUEST;
USETW(req.wValue, 0);
- USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
+ if (sc-sc_chiptype == CHIPTYPE_PL2303X)
+ USETW(req.wIndex, 0x61);
+ else
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
USETW(req.wLength, 0);
err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0);
@@ -713,6 +731,43 @@
return (0);
}
+#define DO_REQ(type, reQ, wVal, wInd) do {\
+ req.bmRequestType = (type); \
+ req.bRequest = (reQ); \
+ USETW(req.wValue, (wVal)); \
+ USETW(req.wIndex, (wInd)); \
+ USETW(req.wLength, 0); \
+ err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0); \
+ if (err) { \
+ printf(%s: uplcom_initPL2303X_%d: %s\n, \
+ USBDEVNAME(sc-sc_ucom.sc_dev), i++, usbd_errstr(err)); \
+ return (EIO
[Fwd: Re: strange ucom (uplcom) error]
Emanuel Strobl wrote: Am Dienstag, 18. Januar 2005 16:17 schrieb Andrew L. Neporada: On Tue, Jan 18, 2005 at 01:06:43PM +0100, Emanuel Strobl wrote: Dear experts, I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working the other one not (I hate to say it but both are working under win). The not working (more expensive) one gets recognized as ucom0 and I have ucom0, also I can receive signal but not transmit. [skip] Take a look at http://gate.intercaf.ru/~lesha/6100/ and try patch http://gate.intercaf.ru/~lesha/6100/pl2303x.patch It can break old (working) PL2303 chip, but it works for me with newer Thanks a lot, this indeed fixes the revision 3.0 adaptor but unfortunately also breakes the 2.02 version :( Perhaps there's a goog guy out there who can refurbish the uplcom driver with this information (akiyama?)? Thanks a lot, I've just recently been looking into this too. I used the mentioned patch and also linux driver source and have come with the attached patch. It contains one more change but I don't know if it's correct. It works for both chips on CURRENT for serial console. It detects if the chip is rev 3.00 and aplies the patch only for it. The author of the patch mentions it isn't binary safe - sometimes the chip stops working. I planned to test it with binary transfers (ppp) today, check if it's working and submit it (with some cleanup) for inclusion in FreeBSD. Michal Mertl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange ucom (uplcom) error
Sorry to reply to myself but I would better really attach the patch.
I wrote:
Emanuel Strobl wrote:
Am Dienstag, 18. Januar 2005 16:17 schrieb Andrew L. Neporada:
On Tue, Jan 18, 2005 at 01:06:43PM +0100, Emanuel Strobl wrote:
Dear experts,
I have two USB-RS232 Adaptors, both with PL2303 chipset. One is working
the other one not (I hate to say it but both are working under win).
The not working (more expensive) one gets recognized as ucom0 and I have
ucom0, also I can receive signal but not transmit.
[skip]
Take a look at http://gate.intercaf.ru/~lesha/6100/ and try patch
http://gate.intercaf.ru/~lesha/6100/pl2303x.patch
It can break old (working) PL2303 chip, but it works for me with newer
Thanks a lot, this indeed fixes the revision 3.0 adaptor but unfortunately
also breakes the 2.02 version :(
Perhaps there's a goog guy out there who can refurbish the uplcom driver
with
this information (akiyama?)?
Thanks a lot,
I've just recently been looking into this too. I used the mentioned
patch and also linux driver source and have come with the attached
patch. It contains one more change but I don't know if it's correct. It
works for both chips on CURRENT for serial console. It detects if the
chip is rev 3.00 and aplies the patch only for it.
The author of the patch mentions it isn't binary safe - sometimes the
chip stops working. I planned to test it with binary transfers (ppp)
today, check if it's working and submit it (with some cleanup) for
inclusion in FreeBSD.
Michal Mertl
Index: uplcom.c
===
RCS file: /home/fcvs/cvs/src/sys/dev/usb/uplcom.c,v
retrieving revision 1.25
diff -u -r1.25 uplcom.c
--- uplcom.c 6 Jan 2005 01:43:29 - 1.25
+++ uplcom.c 15 Jan 2005 00:44:20 -
@@ -97,10 +97,13 @@
#include sys/sysctl.h
#include sys/uio.h
+#include machine/bus.h
+
#include dev/usb/usb.h
#include dev/usb/usbcdc.h
#include dev/usb/usbdi.h
+#include dev/usb/usbdivar.h
#include dev/usb/usbdi_util.h
#include usbdevs.h
#include dev/usb/usb_quirks.h
@@ -113,30 +116,33 @@
SYSCTL_INT(_hw_usb_uplcom, OID_AUTO, debug, CTLFLAG_RW,
uplcomdebug, 0, uplcom debug level);
-#define DPRINTFN(n, x) do { \
+#define DPRINTFN(n, x) do { \
if (uplcomdebug (n)) \
logprintf x; \
} while (0)
#else
-#define DPRINTFN(n, x)
+#define DPRINTFN(n, x)
#endif
-#define DPRINTF(x) DPRINTFN(0, x)
+#define DPRINTF(x) DPRINTFN(0, x)
-#define UPLCOM_MODVER 1 /* module version */
+#define UPLCOM_MODVER 1 /* module version */
#define UPLCOM_CONFIG_INDEX 0
#define UPLCOM_IFACE_INDEX 0
#define UPLCOM_SECOND_IFACE_INDEX 1
#ifndef UPLCOM_INTR_INTERVAL
-#define UPLCOM_INTR_INTERVAL 100 /* ms */
+#define UPLCOM_INTR_INTERVAL 100 /* ms */
#endif
#define UPLCOM_SET_REQUEST 0x01
#define UPLCOM_SET_CRTSCTS 0x41
-#define RSAQ_STATUS_CTS 0x80
-#define RSAQ_STATUS_DSR 0x02
-#define RSAQ_STATUS_DCD 0x01
+#define RSAQ_STATUS_CTS 0x80
+#define RSAQ_STATUS_DSR 0x02
+#define RSAQ_STATUS_DCD 0x01
+
+#define CHIPTYPE_PL2303 0
+#define CHIPTYPE_PL2303X 1
struct uplcom_softc {
struct ucom_softc sc_ucom;
@@ -156,14 +162,15 @@
u_char sc_lsr; /* Local status register */
u_char sc_msr; /* uplcom status register */
+ int sc_chiptype;
};
/*
* These are the maximum number of bytes transferred per frame.
* The output buffer size cannot be increased due to the size encoding.
*/
-#define UPLCOMIBUFSIZE 256
-#define UPLCOMOBUFSIZE 256
+#define UPLCOMIBUFSIZE 256
+#define UPLCOMOBUFSIZE 256
Static usbd_status uplcom_reset(struct uplcom_softc *);
Static usbd_status uplcom_set_line_coding(struct uplcom_softc *,
@@ -299,6 +306,7 @@
char *devinfo;
const char *devname;
usbd_status err;
+ usb_device_descriptor_t *udd;
int i;
devinfo = malloc(1024, M_USBDEV, M_WAITOK);
@@ -374,7 +382,14 @@
sc-sc_isize = UGETW(ed-wMaxPacketSize);
}
}
-
+ udd = dev-ddesc;
+ if (UGETW(udd-bcdDevice) == 0x300) {
+ DPRINTF((chiptype 2303X\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303X;
+ } else {
+ DPRINTF((chiptype 2303\n));
+ sc-sc_chiptype = CHIPTYPE_PL2303;
+ }
if (sc-sc_intr_number == -1) {
printf(%s: Could not find interrupt in\n,
USBDEVNAME(ucom-sc_dev));
@@ -617,7 +632,10 @@
req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
req.bRequest = UPLCOM_SET_REQUEST;
USETW(req.wValue, 0);
- USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
+ if (sc-sc_chiptype == CHIPTYPE_PL2303X)
+ USETW(req.wIndex, 0x61);
+ else
+ USETW(req.wIndex, UPLCOM_SET_CRTSCTS);
USETW(req.wLength, 0);
err = usbd_do_request(sc-sc_ucom.sc_udev, req, 0);
@@ -713,6 +731,43 @@
return (0);
}
+#define DO_REQ(type, reQ, wVal, wInd) do {\
+ req.bmRequestType = (type); \
+ req.bRequest = (reQ); \
+ USETW(req.wValue, (wVal)); \
+ USETW(req.wIndex, (wInd)); \
+ USETW(req.wLength, 0); \
+ err = usbd_do_request(sc
syslogd stopping to work
After upgrade from 4.2-REL to 4.4-SECURITY syslogd stops logging after several days of operation. I use it to log routers and such and it's pretty important for me. I don't want to use some different syslogd unless absolutelly necessary. It has happened already several times. 'ps axO wchan' gives '49083 sbwait ?? Is 0:06.07 /usr/sbin/syslogd -a '. CPU usage is 0% and the daemon stays like this forever. I have built the binary with debug information and have the coredump. The backtrace (I sent the daemon ABORT signal) is: #0 0x280a7674 in recvfrom () from /usr/lib/libc.so.4 #1 0x280b4cb4 in res_send () from /usr/lib/libc.so.4 #2 0x280b7e7d in res_query () from /usr/lib/libc.so.4 #3 0x280b7bd3 in freehostent () from /usr/lib/libc.so.4 #4 0x280b5d91 in getipnodebyaddr () from /usr/lib/libc.so.4 #5 0x280b5494 in getnameinfo () from /usr/lib/libc.so.4 #6 0x804b4e2 in cvthname (f=0xbfbff9e0) at /data/src/usr.sbin/syslogd/syslogd.c:1215 #7 0x804a18d in main (argc=9, argv=0xbfbffb8c) at /data/src/usr.sbin/syslogd/syslogd.c:546 #8 0x8049745 in _start () From my reading of it it seems syslogd tries to do reverse DNS loookup (will be disabled by -n ?) and hangs in it. It's quite possible that there was interminent problem with DNS. May be the problem isn't in syslogd but in resolver. Any suggestion as to what else to check? What to do when next time I catch syslogd frozen? I installed cron script which checks the syslog state and for about 14 days it didn't happen :-(. -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
RE: SSH Problem
It seems to me that's because OpenSSH_2.9 has been MFC. It by default has ForwardAgent option off (at least on FreeBSD with default config). You can fix it with ~/.ssh/config or change /etc/ssh/ssh_config Host * ForwardAgentyes -- Michal Mertl [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
