# Errors with external HDD: Software or hardware issue?

## V10lator

Hi,

First off: Ofc. I already backuped all data from the disc.

Now the real problem: Whenever I try to write to the disc errors occur. I did a simple dd if=/dev/zero of=/dev/sdi and looked at the logs:

```
[42726.588295] usb 9-2: new SuperSpeed USB device number 12 using xhci_hcd

[42726.608379] scsi20 : uas

[42726.609107] scsi 20:0:0:0: Direct-Access     Inateck                   0    PQ: 0 ANSI: 6

[42726.609937] sd 20:0:0:0: Attached scsi generic sg10 type 0

[42726.610007] sd 20:0:0:0: [sdi] Spinning up disk...

[42727.609779] ...ready

[42729.780582] sd 20:0:0:0: [sdi] 976773168 512-byte logical blocks: (500 GB/465 GiB)

[42729.780588] sd 20:0:0:0: [sdi] 4096-byte physical blocks

[42729.781461] sd 20:0:0:0: [sdi] Write Protect is off

[42729.781467] sd 20:0:0:0: [sdi] Mode Sense: 43 00 00 00

[42729.781685] sd 20:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

[42729.813825]  sdi: unknown partition table

[42729.815036] sd 20:0:0:0: [sdi] Attached SCSI disk

[42765.910407] sd 20:0:0:0: [sdi] uas_cmd_cmplt ffff88001edd9680 tag 0, inflight: CMD IN

[42765.910413] sd 20:0:0:0: [sdi] cmd cmplt err -71

[42796.634368] sd 20:0:0:0: [sdi] uas_eh_abort_handler ffff88001edd9680 tag 0, inflight: CMD IN

[42796.634481] sd 20:0:0:0: [sdi] uas_cmd_cmplt ffff88001edd9680 tag 0, inflight: CMD IN abort

[42796.634494] sd 20:0:0:0: [sdi] cmd cmplt err -71

[42799.630770] scsi host20: uas_eh_task_mgmt: ABORT TASK timed out

[42799.630804] sd 20:0:0:0: uas_eh_device_reset_handler

[42799.630812] scsi host20: uas_eh_task_mgmt: LOGICAL UNIT RESET: error already running a task

[42799.630820] scsi host20: uas_eh_bus_reset_handler start

[42799.631037] usb 9-2: stat urb: killed, stream 16

[42799.631273] usb 9-2: stat urb: killed, stream 2

[42799.631525] sd 20:0:0:0: [sdi] uas_data_cmplt ffff88001edd9680 tag 0, inflight: CMD abort

[42799.631532] sd 20:0:0:0: [sdi] data cmplt err -2 stream 2

[42799.631576] sd 20:0:0:0: [sdi] uas_zap_dead ffff88001edd9680 tag 0, inflight: CMD abort

[42799.631589] sd 20:0:0:0: [sdi] abort completed

[42799.734948] usb 9-2: reset SuperSpeed USB device number 12 using xhci_hcd

[42799.750400] xhci_hcd 0000:01:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021d9d3c00

[42799.750405] xhci_hcd 0000:01:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021d9d3c48

[42799.750407] xhci_hcd 0000:01:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021d9d3c90

[42799.750409] xhci_hcd 0000:01:00.0: xHCI xhci_drop_endpoint called with disabled ep ffff88021d9d3cd8

[42799.752798] scsi host20: uas_eh_bus_reset_handler success

[42800.825568]  sdi: unknown partition table
```

Here's what I did to try to find the root of it:

- Changed the USB<->SCSI adapter (the external enclosure for the disc).

- Tried MassStorage instead of UAS.

- Changed the USB Port.

- Tried it on a USB 2 port.

- Run a extended self-test (SMART, result: No errors).

I'm getting out of ideas.

```
$ uname -a

Linux horst 3.16.1 #2 SMP PREEMPT Sat Sep 27 22:03:17 CEST 2014 x86_64 AMD Athlon(tm) II X3 455 Processor AuthenticAMD GNU/Linux
```

Also I don't have any other system to test, the only one would be my (dd-wrt) router but it hasn't enough power to spin up the disc.

//EDIT: I attached the disc directly to the internal SATA ports and got no more errors. So it must be something with the USB stack I guess? Any ideas how to track this down?

----------

## V10lator

A new log, this time with disabled UAS:

```
[  873.430504] irq event 46: bogus return value ffffff94

[  873.430512] CPU: 2 PID: 0 Comm: BFS/2 Tainted: G        W  O  3.16.1 #2

[  873.430514] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./870 Extreme3, BIOS P1.60 09/14/2010

[  873.430516]  00000000ffffff94 ffffffff818967bc ffff8800c7aa0900 ffffffff810c0161

[  873.430518]  0000000000000000 00000000ffffff94 00000000ffffff94 ffffffff810bdf52

[  873.430521]  ffff8800c7aa0900 ffff8800c7aa098c ffff88022d810e80 00000000000000d1

[  873.430523] Call Trace:

[  873.430524]  <IRQ>  [<ffffffff818967bc>] ? dump_stack+0x4a/0x75

[  873.430533]  [<ffffffff810c0161>] ? __report_bad_irq+0x21/0xc0

[  873.430536]  [<ffffffff810bdf52>] ? handle_irq_event_percpu+0x92/0x100

[  873.430538]  [<ffffffff810bdff7>] ? handle_irq_event+0x37/0x60

[  873.430540]  [<ffffffff810c0816>] ? handle_edge_irq+0x76/0x140

[  873.430543]  [<ffffffff8103b055>] ? handle_irq+0x15/0x40

[  873.430546]  [<ffffffff8103a96f>] ? do_IRQ+0x4f/0x100

[  873.430548]  [<ffffffff818a10aa>] ? common_interrupt+0x6a/0x6a

[  873.430549]  <EOI>  [<ffffffff81042b20>] ? amd_e400_idle+0x40/0x100

[  873.430554]  [<ffffffff810aff9f>] ? cpu_startup_entry+0x27f/0x2e0

[  873.430556] handlers:

[  873.430558] [<ffffffff8162c440>] xhci_msi_irq

[  909.114529] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.

[  909.114542] xhci_hcd 0000:01:00.0: Assuming host is dying, halting host.

[  909.122101] xhci_hcd 0000:01:00.0: HC died; cleaning up

[  909.122149] usb 9-2: USB disconnect, device number 2

[  909.124505] sd 8:0:0:0: [sdh] Unhandled error code

[  909.124513] sd 8:0:0:0: [sdh]  

[  909.124515] Result: hostbyte=0x01 driverbyte=0x00

[  909.124518] sd 8:0:0:0: [sdh] CDB: 

[  909.124520] cdb[0]=0x28: 28 00 01 1f 13 a8 00 00 08 00

[  909.124528] end_request: I/O error, dev sdh, sector 18813864

[  910.156229] sd 8:0:0:0: [sdh] Synchronizing SCSI cache

[  910.156295] sd 8:0:0:0: [sdh]  

[  910.156301] Result: hostbyte=0x01 driverbyte=0x00
```

So could it be that a IRQ is the cause of all evil and if so: How to debug/fix?

----------

## V10lator

I disabled MSI-X IRQs for XHCI by adding this to drivers/usb/host/xhci.c line 308:

```
   //Always disable MSI-X:

   ret = -1;

   goto disable_msix;
```

Result: http://pastebin.com/4eC8PjMu

I'm not sure if this is better or worse than before. At least I noted the dmesg spam immidiately...  :Rolling Eyes: 

----------

## V10lator

I used a fresh vanilla 1.17.1 kernel and started debugging from scratch. This time I looked what -71 is, it's -EPROTO. With that knowledge I searched the USB stack for it and, every time it gets set, I added a line that prints out the location in code. So I tracked it down to

drivers/usb/host/xhci-ring.c

static int handle_tx_event(struct xhci_hcd *xhci,

		struct xhci_transfer_event *event)

it's there because trb_comp_code is COMP_TX_ERR. handle_tx_event is called one time only, in the same file:

static int xhci_handle_event(struct xhci_hcd *xhci)

This switch calls it: case TRB_TYPE(TRB_TRANSFER):

So what's calling xhci_handle_event? Well, it's called in irqreturn_t xhci_irq(struct usb_hcd *hcd) (which itself gets called in irqreturn_t xhci_msi_irq(int irq, void *hcd)):

while (xhci_handle_event(xhci) > 0) {}

So I'm back at the question: Is a IRQ freaking out and if so: Why?

----------

## Roman_Gruber

smart on external drives hardly works. for all my tested drives in the past none worked and they were above 10. i think over usb the messages are not handled because of the usb controller in the enclosures usually.

external drives are mostly more damaged because peeps move them around when running which is a very very bad idea.

probably it is dying but i did not read hole of your posts. could be loose cable, broken cable or anything else with your enclosure. put the drive in a known working enclosure and try again or a desctop box to see if the drives is okay.

 *Quote:*   

> vanilla 1.17.1 kernel

  serious?

btw. you can edit your post and do not make always a new one.

 *Quote:*   

> //EDIT: I attached the disc directly to the internal SATA ports and got no more errors. So it must be something with the USB stack I guess? Any ideas how to track this down?

  if you really did not got any more errors than you should have concluded that this external enclosure is fucked up and should be thrown away. assuming you talk about usb / usb2 board it is rather antique hardware anyway. and i assume it is an external drive also.

so summary, based reading in between a broken usb enclosure or cable. replace it and it should be gone high probably.

----------

## V10lator

 *tw04l124 wrote:*   

> robably it is dying but i did not read hole of your posts. could be loose cable, broken cable or anything else with your enclosure. put the drive in a known working enclosure and try again or a desctop box to see if the drives is okay.

 

I tested two different enclosures (with two different cables) and different USB ports. Didn't help. I also tried attaching the disc directly to the SATA bus: No errors.

So either both enclosures are defective (one of them is brand new) or there's a bug in the kernel.

 *Quote:*   

> serious?

 

For testing, yes. It's not my main kernel.

//EDIT:

 *Quote:*   

> if you really did not got any more errors than you should have concluded that this external enclosure is fucked up and should be thrown away. assuming you talk about usb / usb2 board it is rather antique hardware anyway.

 

Actually it's a brand new enclosure (USB3 and UAS). I dislike throwing my money away. Also: "I tested two different enclosures (with two different cables) and different USB ports." (USB2 and USB3 ports). Please stop assuming and read.

----------

## i92guboj

If the drive works fine when attached directly to the SATA bus the problem is crystal clear to me.

Not that I can give you a solution, but I have had nothing but trouble with USB ports in Linux. They never worked ok for me.

I remember back in the old days when having both ohci and uhci drivers together (yes, that box needed both for all the ports to work) caused a hard-freeze from time to time.

When that stopped happening my drives would just refuse to work after some minutes with log spamming which was very similar to yours. I have returned many enclosures to the shop thinking that they would be defective, but no, it wasn't the enclosure, it was just USB in the linux kernel. The thing is that nowadays, regular usb devices work just fine (pendrives, mouse receivers, wifi dongles, etc.). But anything requiring more power often fails (my dvd writer doesn't work reliably either). It might be pure coincidence though, since all the hard disk cases I used had and external power supply (hence they didn't depend on USB for that).

I do some IT around here and there, and all these devices will work fine under other OSes, but they fail in all my Linux based machines (they have for more than a decade, so, again, it's clear where the problem lies).

You only need to google around to see that this is not a rare issue.

I am sorry I can't offer a proper solution.

The people above has a point about the SMART stuff though. If you want to be relatively sure about the results, you should run the SMART test with the drive attached to the SATA bus, not via USB.

----------

## NeddySeagoon

V10lator,

 *V10lator wrote:*   

>  ... only one would be my (dd-wrt) router but it hasn't enough power to spin up the disc

 

You mean the enclosure does not have its own power brick?

USB2 cannot supply the power to reliably operate a HDD.

Such enclosures are nomally supplied with a USB 'Y' cable so that they can draw power from two USB ports

It actually worse than that. You need to connect the 'Y' to two different USB root hubs. A root hub being two stacked USB ports.

Worse still, you must not connect anything else to the root hubs powering your HDD, unless its self powered.

In short, USB HDDs without a power brick should be avoided.

There is a glimmer of hope. A USB3 port can provide 900mA, which is almost twice that of USB1/2.

It might work from a USB3 port.

----------

## V10lator

 *NeddySeagoon wrote:*   

> You mean the enclosure does not have its own power brick?

 

No, it hasn't.

 *Quote:*   

> USB2 cannot supply the power to reliably operate a HDD.

 

On many desktop PCs it can, till now mine could operate with every device, no matter how much out of spec.

 *Quote:*   

> Such enclosures are nomally supplied with a USB 'Y' cable so that they can draw power from two USB ports

 

As my old enclosure. But that shows the same errors.

 *Quote:*   

> Worse still, you must not connect anything else to the root hubs powering your HDD, unless its self powered.

 

I have a powered (not root) hub. tried it there, too.

 *Quote:*   

> There is a glimmer of hope. A USB3 port can provide 900mA, which is almost twice that of USB1/2.
> 
> It might work from a USB3 port.

 

No, it doesn't. BTW: It's a USB3 enclosure (how many times did I say that now?). The disc itself needs 0.55A, slighly above USB1/2 spec, USB3 should be able to handle it.

Anyway, I'll re-test the enclosures with the help of a friends laptop soon.

----------

## NeddySeagoon

V10lator,

You have done all the right tests.

I'm aware that some broken systems can supply well over 500mA from a USB2 port.

Some are not even short circuit protected - the +5v track to the port blows.

As you say, with UBS3 you shoud be good, as long as its USB3 all the way - including a good quality USB3 cable.

Something to look at. Motherboards often have a jumper to choose the +5v power source for some USB ports.

It should be set to +5v, which is the main PSU 5v output.  5v STBY is much lower power and poorly regulated. That jumper position is intended only for USB devices that need to be able to wake up the system, so that they are always powered.  Don't run your HDD off the  5v STBY.

Sorry for missing your USB3 reference.

----------

## V10lator

@NeddySeagoon Thanks for all the tipps but I really don't think it's a power issue.

@i92guboj Also thanks for all the hints but bugs can't be fixed if the root is unknown, that's why I want to track this down as much as possible before opening a bugreport at the kernels bugzilla.  :Smile: 

----------

## Roman_Gruber

 *V10lator wrote:*   

> 
> 
>  *Quote:*   Such enclosures are nomally supplied with a USB 'Y' cable so that they can draw power from two USB ports 
> 
> As my old enclosure. But that shows the same errors.
> ...

 

That is a violation of the usb specification (no idea about usb 3.0). well they are sold like that but they are never safe or intended for that behaviour. 

if you have a y cable just plug in the mian port. the usb are usually bricked for the power anyway on the mobo.

You can call teh y cable a marketing gag, thats it

----------

## krinn

- You said disk need 0.55A so above usb2 specs, so any usb2 tests should be considered as a failure.

- You said disk work on sata

- You said you tried two (same model?) cases, diff cables...

- You said you tried a diff kernel (a vanilla 1.17.1 kernel, something that shock tw04l124 and myself too, but you confirm that).

So you can say :

1 might comes from bios usb handling

2 might comes from case handling

3 might comes from kernel usb handling

4 the Holmes : when you have eliminated the impossible, whatever remains, however improbable, must be the truth

Let's see 1:

Nothing really to check, but the manufacturer site to look for latest bios, take great care of message from manufacturer like "improve usb keyboard handling" or "fix usb support when suspend" or the like messages : because no manufacturer would produce any "fix usb failure/malfunction", but hide it behind a more generic and harmful message. Manufacturer may produce shitty bios or board, it doesn't mean they will tell everyone they did thru a bios upgrade message  :Smile: 

2 :

Consider check for weird conception : usb3 case to handle sata3 drive may just act weird with a sata2 drive plugin, i know it's silly, but silly errors comes from silly conception. Check the drive met the "written" specs of the case.

I might also include there, hardware made and test with Windows (so tweak to handle Windows bugs) that just fail when plug on an os without the bug.

3:

Of course kernel, you did try with an old kernel, but alas your test was not good because no kernel 1.17 could support usb3, making any test with it at best usb2 (i'm not even sure usb2 is handle by a 1.17), and we knows any usb2 tests is just a failure because it cannot gives enough power to the drive (while it's to note, that the power taken from usb is for the drive AND the case, and not only the drive).

Also kernel options may show bugs only with another option, so better use a config not from yourself (people have habit to re-add always the same options, even they don't know the options, they just re-add them as a "it was ok with them, keep them")

4:

In that category i would put the weirdest possible case : that case model isn't working with that harddrive model (it looks really dumb, but even i never seen something like that with an usb3 case, i have seeing something like that for many other hardware that were both ok with their specs ; i have seen maxtor disk model unable to work with a pata controller, while the controller was working ok with any other disk model, and the maxtor was ok on other pata controller).

In that category, i would include user infos, as i highly suspect you didn't test a kernel 1.17 but with a 3.17, it should be kind of complicate to run a 1.17 today.

Of course case 2 can be add in that section, but it's a too common error that i'm not considering it as impossible anymore.

To me i would reconsider 3, kernel bug with usb3 (that is still early for kernel and you can just look at kernel changelog to see how much usb3 handling in linux is moving and changing). Because your kernel test was a failure. And because the kernel usb3 driver looks far from a stable state for me.

I would goes with a vanilla latest kernel to test and an older (but not a prehistoric kernel like you did), something like a 3.4 serie. Tell me it's feeling or guess, but that's where i would put my bets on.

I would next goes check 1 (no name need, all board builders always release buggy bios with their board).

----------

## V10lator

 *krinn wrote:*   

> (a vanilla 1.17.1 kernel, something that shock tw04l124 and myself too, but you confirm that).

 

Oh whoops, sorry for that. I wanted to say a 3.17.1

 *Quote:*   

> 1 might comes from bios usb handling

 

No problems with other USB devices, no problems (in the past, right now no stick available to test) with USB Sticks, latest BIOS installed.

 *Quote:*   

> Consider check for weird conception : usb3 case to handle sata3 drive may just act weird with a sata2 drive plugin, i know it's silly, but silly errors comes from silly conception. Check the drive met the "written" specs of the case.
> 
> I might also include there, hardware made and test with Windows (so tweak to handle Windows bugs) that just fail when plug on an os without the bug.

 

I looked at the spec: "Supported drives: 2.5'' SATA I/II/III HDD/SSD". As always Linux isn't listed as compatible OS, but OS/X is.

 *Quote:*   

> 3

 

Might try a genkernel soon.

 *Quote:*   

> 4

 

The drive is a WD Scorpio Black (WD5000BPKT - 75PK4T0). I use WD drives only as other vendors always f*cked up one or the other way (early dieing drives, drive doesn't work with every controller, ...). That's a rule I'm following since around 7 years.

 *Quote:*   

> To me i would reconsider 3, kernel bug with usb3

 

Does happen with at USB2 ports, too, even when there's a powered USB hub between the PC and the enclosure (and the PC never had any problems with any USB device requiring more than 500mA).

 *Quote:*   

> something like a 3.4 serie. Tell me it's feeling or guess, but that's where i would put my bets on.

 

Will try 3.4.104 LTS soon.

//EDIT: And yes, I tested 2 different enclosures (with 2 different controllers).

//EDIT²: I just double checked that the enclosures really have different controllers and while this is the case the manufacturer is the same. One is ASMedia Technology Inc. ASM1053 and the other ASMedia Technology Inc. ASM1051. So maybe the kernel has problems with ASMedia chips?

----------

## krinn

 *V10lator wrote:*   

> So maybe the kernel has problems with ASMedia chips?

 

That's what i said, considering kernel problem with usb3 first, as all kernels changelog always got some fix for usb3 ; chance some more bugs remains (or a regression).

----------

## V10lator

 *krinn wrote:*   

>  *V10lator wrote:*   So maybe the kernel has problems with ASMedia chips? 
> 
> That's what i said, considering kernel problem with usb3 first, as all kernels changelog always got some fix for usb3 ; chance some more bugs remains (or a regression).

 

Well, for now I talked to the manufacturer of the enclosure and it seems like he wants to know what's going on, too: I'll get a new case and a USB3 Y cable for free.  :Smile: 

Also I'm currently testing the same disc with a old USB2->SATA adapter with a JMicron controller.

----------

## Ant P.

All the evidence here points to crap firmware or silicon — it survives the spin-up and lives long enough to identify the disk, but fails straight away on the command after that. UAS and XHCI are both kinda exotic right now, but since you've already ruled out both I'm leaning toward it being a bug in the enclosure.

I don't really have anything helpful to add besides good luck fixing it; I know from experience low-level USB can be a huge pita to debug.

----------

## krinn

 *V10lator wrote:*   

> Well, for now I talked to the manufacturer of the enclosure and it seems like he wants to know what's going on, too: I'll get a new case and a USB3 Y cable for free. 

 

What is the manufacturer? How they manage your issue is worth mentioning, i would buy products from a manufacturer with that spirit.

----------

## V10lator

 *krinn wrote:*   

> What is the manufacturer?

 

Inateck.

----------

## V10lator

The new case and the Y cable are here, but still the same errors. I just catched this:

```
[ 2284.092419] irq event 46: bogus return value ffffff94

[ 2284.092428] CPU: 2 PID: 1791 Comm: Media Tainted: G        W  O  3.16.1 #8

[ 2284.092430] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./870 Extreme3, BIOS P1.60 09/14/2010

[ 2284.092431]  00000000ffffff94 ffffffff818967bc ffff8800c7ac3c00 ffffffff810c0161

[ 2284.092434]  0000000000000000 00000000ffffff94 00000000ffffff94 ffffffff810bdf52

[ 2284.092436]  ffff8800c7ac3c00 ffff8800c7ac3c8c ffff88022d88e880 00000000000000d1

[ 2284.092437] Call Trace:

[ 2284.092439]  <IRQ>  [<ffffffff818967bc>] ? dump_stack+0x4a/0x75

[ 2284.092448]  [<ffffffff810c0161>] ? __report_bad_irq+0x21/0xc0

[ 2284.092450]  [<ffffffff810bdf52>] ? handle_irq_event_percpu+0x92/0x100

[ 2284.092452]  [<ffffffff810bdff7>] ? handle_irq_event+0x37/0x60

[ 2284.092454]  [<ffffffff810c0816>] ? handle_edge_irq+0x76/0x140

[ 2284.092457]  [<ffffffff8103b055>] ? handle_irq+0x15/0x40

[ 2284.092459]  [<ffffffff8103a96f>] ? do_IRQ+0x4f/0x100

[ 2284.092461]  [<ffffffff818a10aa>] ? common_interrupt+0x6a/0x6a

[ 2284.092462]  <EOI> 

[ 2284.092463] handlers:

[ 2284.092465] [<ffffffff8162c440>] xhci_msi_irq

[ 2319.157775] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.

[ 2319.157780] xhci_hcd 0000:01:00.0: Assuming host is dying, halting host.

[ 2319.165042] xhci_hcd 0000:01:00.0: HC died; cleaning up

[ 2319.165065] usb 9-2: USB disconnect, device number 2

[ 2319.166726] sd 8:0:0:0: [sdh] Unhandled error code

[ 2319.166732] sd 8:0:0:0: [sdh]  

[ 2319.166733] Result: hostbyte=0x01 driverbyte=0x00

[ 2319.166735] sd 8:0:0:0: [sdh] CDB: 

[ 2319.166736] cdb[0]=0x28: 28 00 03 6e f7 40 00 00 08 00

[ 2319.166741] end_request: I/O error, dev sdh, sector 57603904

[ 2320.975694] sd 8:0:0:0: [sdh] Synchronizing SCSI cache

[ 2320.975730] sd 8:0:0:0: [sdh]  

[ 2320.975732] Result: hostbyte=0x01 driverbyte=0x00
```

Again something with the IRQs, no? Should I open a bug report now and if so: To whom? I guess it's a problem with the IRQs in combination with ASMedia devices, but who's responsible for that?

//EDIT:

 *Ant P. wrote:*   

> All the evidence here points to crap firmware or silicon — it survives the spin-up and lives long enough to identify the disk, but fails straight away on the command after that.

 

No, it lives longer. The failures are random, example from the log above (I started copying right after it attached the disc, 29 GB where copied before the failure) :

```
[  161.142106] sd 8:0:0:0: [sdh] Attached SCSI disk

[ 2284.092419] irq event 46: bogus return value ffffff94
```

----------

